I'm trying to use a kibana trigger from a monitoring alert using the message box to formulate a kibana link that sends it to a specific kibana dashboard for a time period of the last 7 days from the time the alert is triggered and send it to a slack webhook.
I'm using the ctx.periodStart variable as my ending period. Is it possible to get the exact timestamp that's 7 days from the ctx.periodStart timestamp as part of my kibana trigger message (In other words, if the ctx.periodStart timestamp is 2022-04-11T19:19:25Z as my period ending range, I want to have the beginning timestamp value at 2022-04-04T19:19:25Z)? I can't seem to find anything that can do this. The only way around this issue is to use the ctx.results.0.hits.hits.0._source.timestamp variable as my starting period and that timestamp value is a bit earlier than the exact 7 days from the ctx.periodStart timestamp. Using a relative time period (like now-7d) isn't going to cut it because we fire this kibana monitor alert every Friday at noon to grab a query where we know we will get at least 1 hit and every Tuesday at midnight where we know we are not likely to get any results from the query. And since we know that this alert will go to a slack message with the kibana dashboard link once a week, putting a relative time period like 'now-7d' is going to mess up the kibana links for past slack alerts from the same kibana monitoring alert.
Thanks.
Related
Some events don't take place at any specific time and instead are meant to be valid for the whole day irrespective of the time zone the user is at.
For the sake of argument, let's say a system sitting on a server (up in the cloud) runs a job at 5 am and imports data from a different system between this run and the last (24 hours ago). The actual user sitting at his desk doesn't know when the job runs, the user only knows that they go to sleep at night, the server crunches all the entries for the day.
The next morning the user wants to see all the entries from yesterday (what ever the job produced) and they go to the app, pull up a calendar input selector and they pick the 5/26/2022 (today being 5/27/2022).
Assuming the developers followed best practices, the client will transform the date into it's UTC version and send it up through an API. Chances are, depending on where the user is located and the server is, there might be a mismatch.
I could send the date up without it being UTC or I could send a UTC date and try to adjust it back to local time so that I could then compare with the date on record (that exists without an actual time zone).
What I am asking is:
What's the more conventional answer to this particular problem?
Is the idea of a date without time or time zone just ridiculous?
Use UNIX Time. It will give you a timestamp that is universal no matter what timezone the user is in. You can then convert it into whatever timezone you want to.
The concern you describe is well solved/addressed by the ISO 8601 dates/time presentation protocol.
All modern software can read/write dates in ISO 8601.
In Unix machines, the correct command is date with option -I
-I[FMT], --iso-8601[=FMT]
output date/time in ISO 8601 format. FMT='date' for date
only (the default), 'hours', 'minutes', 'seconds', or 'ns'
for date and time to the indicated precision. Example:
2006-08-14T02:34:56-06:00
Im a bit new at azure devops and I am trying to view task that was not close in the same day it was activated/ when its state was changed using query. My point of confusion is that I dont know how compare the state change date with the close date.
the output should be tasks that are still active and task that are closed but not in the same date it state was change
UPDATE
So I was wondering if my approach was wrong so I tried different approach.
here I try using the []<> to compare completed date with activation date, it should have sorted to show only task that the activation date are different from the close date but here I still got shown tasks which have close date and activation date in the same date.
UPDATE 2
Since I cant use the '[]<>', I decided to use the not so smart way to compare the task close date, active date, and create date as seen in the screenshot below, it is ugly but it works. If anyone knows a smarter way to do this, please do tell.
My current solution
I still got shown tasks which have close date and activation date in the same date.
The reason for this problem you met is that when you use the condition “Closed Date <>[Field] Activated Date”, the values of these two fields are actually datetime format which means it contains hours, minutes and seconds like below:
That’s why you can still see the records shown with same date.
As for the requirement you mentioned, there’s no directly available solution you can use in Azure DevOps Query as far as I know.
In addition, please refer to Group clauses where you can see how to set conditions for “not close in the same day it was activated/ when its state was changed”, like below:
I have a daily count metric being pushed to prometheus. Its important to have the measurement every few minutes, but I also want the measurement at a specified time (end of the day) to see the daily total. Is there a way to specify a time of the measurement?
I have set the min_step (time step) to be 24h. Doing so gives me measurements at 20:00:00 each day. Ideally this would be 23:50:00 through 23:59:59
The chart type is a Graph, and the PromQL query is:
max(table_row_count) by (table)
with min_step = 24h, format = time series, and min time interval = 24h. Relative time is set to 7d to get a weekly view of the tables.
I am expecting some way to be able to set the timestamp of the query that should be run every 24h.
Prometheus doesn't have any cron features. You would have to revert to scheduling it yourself.
This means that the first requirement is to get the data you want at the given time. This can be easily done by a GET on the url of the metric you want. (by example using curl).
Now, the question is how to feed it to prometheus. I see three possibilities:
dump the content in a file and let node exporter expose it to prometheus (and erase it after a time). A careful rewrite of metrics can be used in prometheus to sanitize it.
write your own exporter to expose it (easy to do, especially since you have the right data format)
push it to a push gateway but there is currently no way to make the data expire.
I'm testing some API calls and was delighted to see that the seven-day forecast was including the current day. Around mid-day my time, the seven-day forecast changed and started returning tomorrow as the first day instead.
https://developer.here.com/documentation/weather/topics/example-seven-day-weather-forecast.html
My theory is that the servers are in California (or similar timezone). I'm in Stockholm. It was probably still "yesterday" in the server's timezone when I started playing with the APIs.
Any suggestions on how to fix this? Ideally, I'd like to see an additional parameter allowing me to specify my timezone, or (even better) automatic timezone detection of the requester.
The requester's timezone is not used in the retrieval of the weather data. The reference time(zone) is the local time of the location of which weather data is requested. For the seven days weather forecast, the next day is chosen as the start day if the local time is after 15:00.
Using forecast_hourly as product parameter will give you hourly weather data starting from the current local day and not the next day.
I have a leave workflow which is working fine with no issues
What I want to do is to pause the workflow 2 days(48 hours) before start date of the workflow/leave request
When applying for leave you supplier a start date and the end date, just before the initiator goes on leave the workflow should pause\let the line manager know 2 days before going on leave.
Could someone assist me in doing this in a nintex workflow 2013
Appreciate any help
Thanks
Two ways of doing this, first you need to calculate a date based on the start date .. Use the date calculation action to -2 from the start date.. You cam then place a pause in the workflow until that date and send notifications.. A better way of doing it and more robust. Would be to record the date -2 from start date in the content type as a hidden field. Then have a site workflow scheduled to run every morning and cycle through all pending leave requests looking for dates that fall on this day. If the -2 date falls on the day of site workflow execution then post msg to manager to inform them of their staff leave in 2 days time.
For further Nintex related questions please post them to the http://community.nintex.com website