-
-
Notifications
You must be signed in to change notification settings - Fork 38
Troubleshooting
Your execution policy is likely set to Restricted, which prevents the execution of all scripts, including those downloaded from the PSGallery. To execute scripts on your local machine you must relax your execution policy to either RemoteSigned or Unrestricted
Set-ExecutionPolicy RemoteSignedThe exact reason the PrtgAPI module cannot be loaded can be confirmed by running the command Import-Module PrtgAPI
Your server does not support HTTPS. Manually specify http:// instead
Due to the way the PRTG API is structured and API authentication works, PrtgAPI primarily uses HTTP GET requests for interacting with PRTG, even for requests that would normally be executed as POST requests by the PRTG UI. A major consequence of this however is that if an API request is too large (that is to say, the URL that PrtgAPI attempts to execute is beyond a certain limit, typically in the order of 2000+ characters) then PRTG's web server will drop the API request, resulting in this error message.
Typically this is only really an issue when you are specifying too many request filters or objects to add in a single request. In order to work around this, you should consider splitting your request up into a series of smaller API requests. Please see this explanation of a way you can easily achieve this.
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel
Your server's SSL certificate is invalid, or you are attempting to connect to an SSL-enabled server via an IP Address. If your server has not properly been configured to use HTTPS, you must configure it to use HTTP instead. This can be done in the PRTG UI under Setup -> System Administration -> User Interface -> Web Server: TCP Port for Web Server
Alternatively, you can specify that PrtgAPI should ignore SSL errors when communicating with your PRTG server. When using PrtgAPI under the .NET Framework or Windows PowerShell this will affect all requests to your server for the life of your process. In .NET Standard and PowerShell Core this is merely limited to the life of your client.
//C#
var client = new PrtgClient("prtg.example.com", "username", "password", ignoreSSL: true);# PowerShell
# Specify to ignore SSL errors upon establishing a connection
C:\> Connect-PrtgServer prtg.example.com -IgnoreSSL
# Update an existing PRTG connection
C:\> goprtg
C:\> Set-PrtgClient -IgnoreSSLYour PRTG server has been locked down to only support TLS 1.2, however you are running on a version of .NET Framework that doesn't support TLS 1.2 by default. (Note that from PrtgAPI 0.9.12, due to changes in PRTG 20.1.55 TLS 1.2 support is now automatically enabled by PrtgAPI for you).
To communicate with servers running TLS 1.2 using PrtgAPI versions earlier than 0.9.12, you must manually instruct .NET to use this protocol
//C#
ServicePointManager.SecurityProtocol = ServicePointManager.SecurityProtocol | SecurityProtocolType.Tls12# PowerShell
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12TL;DR: Increase PRTG Server specs or speak with Paessler
When executing API requests (in particular requests that create or modify objects) against a large number of objects, or indeed - on any amount of objects when running a large PRTG installation (5000-10000+ sensors) - you may experience issues such as:
- PRTG slows down considerably
- the UI becomes almost unusable
- API requests take a lot longer to complete
- memory usage of the PRTG Core Server service increases substantially
- Performance effects do not die down after you have finished completed executing API requests
In the event you experience any of these issues, please note these issues are caused by the design of PRTG, not PrtgAPI. PRTG has a stateless, RESTful API that the PRTG UI and PrtgAPI both consume; as such, there is no "session management" that needs to be controlled. Every API request that is executed is completely standalone. When you create a PrtgClient, all it does is record the authentication credentials to use in every web request. In the case of PRTG API v2, the PrtgClient also encapsulates an authentication token that the server hands out that expires an hour after it has been granted, however this completely separate from any API requests you actually execute with that token so cannot explain any performance issues you are encountering.
In my personal experience (which is largely based on PRTG 17 and prior) PRTG does not appear to be very well written software. The fact that the PRTG UI would slow down during or even for a while after API requests have finished executing is evidence that the internal systems of the PRTG Core Server are not sufficiently separated. When memory usage of the PRTG Core Service increases, ostensibly this memory should then be freed as soon as it is no longer needed. Potentially, over time the memory usage may die back down again, however if you find it never decreases this indicates that PRTG in fact has a memory leak - in which case this is a bug that should be escalated to Paessler.
In my experience, running PRTG with a large number of sensors can be very tough. The following is a list of recommendations you can consider in your environment that may or may not help with the issues you are experiencing
-
Give the core server way more RAM than it needs. At 10,000 sensors ~16gb is a good mark. Even if it doesn't use it all, as long as theres a several GB free you're probably fine for normal fluctuations + questionable growth that may or may not be memory leaks
-
Give the core server way more CPU than it needs. If you look at Task Manager, you might think to yourself: the CPU is doing nothing! Why is it running slow!
This was exactly my experience on a server with 8-12xCPU (I can't remember) and 13,000 sensors. As a test, we bumped it up to 16xCPU and were blown away at the overall performance improvement - this was simply utilizing the web UI though, nothing to do with using the API. Again, the CPU usage per core was still non-existent, indicating me potentially the issue is simply the PRTG Core Server has too many threads to juggle, and having a lot of cores reduces the amount of context switching that needs to take place
-
Make sure your sensors are distributed across a lot of probes. In my current environment, I prefer to do as little as possible on the Core Probe to reduce the chance of issues happening on my core server. You can potentially use PrtgDocker to run multiple probes on a single Windows Server system, if that may be of use to you
-
Implement a weekly core restart. You should do this in Windows via a scheduled task, rather than PRTG's built-in restart system (the whole issue is that PRTG is unreliable, so you shouldn't be relying on PRTG to take care of itself)
In the event you are unable to resolve your performance issues yourself, you will most likely need to raise a support case with Paessler. If you do happen to mention you're using PrtgAPI to your support representative, you should not let them get distracted by the notion that PrtgAPI is a whole separate "product"" - "we don't support PrtgAPI" - API requests are API requests; the issue has nothing to do with PrtgAPI, it has to do with how PRTG is handling the API requests it receives.
Good luck!
PrtgAPI is capable of emitting verbose logging information via the LogVerbose event handler of a PrtgClient
client.LogVerbose += (sender, args) => {
Console.WriteLine(args.Message);
};The most common type of logging used by PrtgAPI is emitting the HTTP URL that was constructed and how it is going to be executed (synchronously, asynchronously or via streaming). By copying and pasting this URL from the event handler directly into your web browser, it is possible to tweak and modify requests and see exactly what the output is. This can be quite useful when you're the lead developer on a C#/PowerShell module that basically revolves around executing web requests.
The types of events logged by PrtgAPI can be controlled via the LogLevel property of the PrtgClient. By default, only Request and Trace messages are logged.
//Log only request/response messages
client.LogLevel = LogLevel.Request | LogLevel.Response;PrtgAPI cmdlets are capable of emitting verbose logging information, including the HTTP URL they are executing, based on the value of the Verbose Action Preference, controlled via $VerboseActionPreference or by specifying -Verbose to the cmdlet you wish to analyze
C:\> Get-Device -Verbose | Get-Sensor | Pause-Object -Forever -Verbose
VERBOSE: Get-Device: Synchronously executing request http://prtg.example.com/api/table.xml?content=devices...By default, only Request and Trace messages are logged. This can be modified by specifying a -LogLevel to Connect-PrtgServer or calling Set-PrtgClient after a session has been established
Set-PrtgClient -LogLevel AllWhen developing applications utilizing PrtgAPI with Visual Studio, if something doesn't seem right or you're generally curious as to how something works, you can step into the PrtgAPI source code by utilizing SourceLink. SourceLink requires Visual Studio 2017+
To configure SourceLink on a stock install of Visual Studio
- Navigate to Tools -> Options -> Debugging -> General and make sure Enable Just My Code is disabled
- Navigate to Tools -> Options -> Debugging -> Symbols and make sure you have the NuGet Symbol Server. If not, simply add the server
https://symbols.nuget.org/download/symbolsand make sure it is enabled
Upon stepping into a PrtgAPI method, you should get a prompt asking you whether you'd like to download sources from GitHub. Select yes, don't ask again.