jhume
Regular Visitor
Joined 2 years ago
User Profile
User Widgets
Contributions
Two new Variables Needed for Alert Templates
I'd like to be able to send Alerts from AlertSite into the Dynatrace Third Party Synthetics Events API. However, I can't because Dynatrace's POST API requires two values that aren't available with the currently provided variables in the Alert Template editor. The following two variables are needed: UTC_Epoch_Time_ms - Dynatrace requires the event timestamp field to be in UTC Epoch milliseconds (like this: 1727110341000). AlertSite's DT_Status variable is a formatted timestamp string, plus it's in the time zone that the account is set to (which is a whole other can of worms...). Alert_ID - Dynatrace's API requires a unique Event ID value. I can kind of simulate one by putting the Monitor ID value and DT_Status variables together so that we get a unique ID. But it'd be nice if some kind of unique ID number would be available via a variable (surely in the AlertSite database these Alerts have unique ID's for each of them, just give us a variable to pass that on). As it is now, I have to write a script that will regularly query the AlertSite API to see if there is an alert and, if so, pass on a properly formatted Event message. It's a shame as using the AlertSite Alerts would be much more appropriate and efficient...240Views2likes4CommentsRe: Please return all AlertSite API results in UTC time
Man, I'm revisiting this as we REALLY have a need to be able to query data into Grafana from AlertSite, but it just isn't possible without setting our ENTIRE account to use UTC time, which would make the web console extremely confusing for all users as they'd have to convert the UTC time to their own local time.79Views0likes0CommentsRe: Displaying the data based on custom time zone or based on end user's device/browser timestamp
Yeah, but the problem with setting the timezone for the whole account is that, especially in today's modern work-from-home times, we have users in multiple timezones. Having the timezone be static for all users just creates confusion. It also effects the API timezone, which means, unless we set the whole account to display in UTC time, we can't use the AlertSite data in dashboarding tools like Grafana that require the data to be in UTC time. But, if we set the account to output in UTC time, that means everyone that now uses the dashboard must manually subtract anywhere from 4 to 7 hours from the time they see based on what timezone they are in and whether it is currently daylight savings or not. This is extremely confusing and makes working with the tool extremely cumbersome. It really should be setup to where all results are stored in UTC time (a longstanding industry standard. And I do mean UTC, not GMT, as GMT is a deprecated standard and should not be used anymore) and that the time shown in the web console is solely based on the end-users' browser timezone and all results retrieved from the AlertSite API are in UTC time. This is how nearly every monitoring tool and website I've used works. Even SolarWind's web console, which is over 15 years old, has always worked this way. But, even if the ability to display time based on end users' browser time isn't made available, at least the option to have API results returned in UTC time should be made available so that tools like Grafana or Dynatrace can retrieve results from the AlertSite API without having to have a script or custom plugin in between to modify the time. I went ahead and created a Feature Request for this as well: Please return all AlertSite API results in UTC tim... - SmartBear Community551Views0likes0CommentsPlease return all AlertSite API results in UTC time
Currently any results from the AlertSite API are returned using whatever time zone is configured for the entire account. The problem with that is that the widespread standard used by most tools/apps is to assume that API results are in UTC time. Because of this, we are unable to pull data from the AlertSite API into tools like Grafana or Dynatrace, not without having some kind of custom script in between to modify the time fields to UTC. Please either change all API results to use UTC time, regardless of the account settings, or at least add a parameter to all API Requests to have the results returned in UTC time. Or, maybe a setting in the Accounts page that toggles all API results to use UTC time? Also, when I say UTC, I don't mean GMT, as that is a deprecated method of storing and displaying time, since GMT has to be adjusted based on whether or not Daylight Savings time is currently active. UTC does not have this limitation, hence it's widespread use in nearly every modern database and/or API).376Views0likes1Comment