Ingest v2 - dates and text status as datapoints

[ct_27]

I'm building a monitor for another technology and we need to track current status (Running, Complete, Misfire) and the date of last run.

There have been some suggested tricks on using dimensions to hold the Status value but it hasn't been very reliable or a robust solution. Sometimes the analysis results return all 3 status values should they have all occurred within the sample timeline. 

I may have read of tricks of storing the date in EPOX as a metric. But then can you get Dynatrace to then represent that as  a date.

Ultimate idea is to then build a dataexplorer data to show

API-----Status------date

name1-------RUNNING-------2/1/2023 16:16

name2-------SUCCESS-------1/30/2023 21:00

name3-------MISFIRE-------2/1/2023 3:00

But then we can run queries that could tell us when was the last successful run. What was the latest STATUS for APIXXX.

[gilgi]

Hey Chad, 

Wouldn't the LAST transformation (https://www.dynatrace.com/support/help/shortlink/api-metrics-v2-selector#last) help you?

Gil.

[dannemca]

How are you sending the data to dynatrace? Time should not be required to be sent as dimension, since it is natively used when ingesting data thru API.

[Julius_Loman]

@ct_27 Metrics in Dynatrace did never fit this use case. Even there was some sort of state type metric in Extesion 1.0 which in fact was a dummy metric value with a state dimension. But only working visual representation was always a Graph.

Can't you just send it as log entries (using Log Monitoring v2 of course) and display them on dashboard? This works, it's easy.

[MichalOlszewski]

Hi @ct_27 

You have 2 approaches here (according Your question) + 1 other if I'm guessing right why are You doing it:

1. As @Julius_Loman said send them as Log Entries with Logs v2 and ten go with it. It will be especially powerful with grail in the future so for SaaS it is the best solution
2. You can send datapoints to single metric with epoch using one dimension for STATUS and second for API_ID. Then You should be able to do so.
3. Considering what is within those data I would recommend using EVENT API and send those data to particular processes/services providing those APIs. Then configure RELEASEs properly and have all about Your APIs, their versions, restarts/failures (from events), issues and so on within single built-in view. And this is what I believe You want to end with.
     

[Julius_Loman]

@MichalOlszewski 

1. Agreed 
2. The issue is not the ingestion of the data, but its visualization. As far as I know, it's not possible to display such data in a table form including the timestamp (representing the last execution). Maybe @zietho knows a trick, but I don't think it's possible with the current visualization options of Data Explorer. It's only possible to view it on the Graph, which is probably not the way you want to display it. Table view in data explorer does not display timestamps.
3. Event API is a good approach,h considering the overall concept and purpose. However, again it fails on the visualization options. Events cannot be displayed on a dashboard at the moment, they only are bound to the entities and displayed on the entity screens. You can have a custom topology type and instance for each job, you will see the events on the entity screen, but there is no way to display them on the dashboard. Unfortunately. Requested several times in product ideas as far as I know. 😐
   
   One of our customers is using a simple external script to fetch desired events and updates a dashboard markdown tile with the event information. It works, it's just not convenient.

[ct_27]

Thank you for understanding the situation and providing some very creative solutions.  I'm going to try leveraging the Release Management module and the markdown solution.  The markdown solution is very creative.  [If MarkUP (true HTML) were permitted in dashboards, that would have been even better.]

I should have time on Friday to try out these ideas and get back to the group with what worked.  Thanks so much for all the suggestions.