How long the telemetry of a single message will be retained on Azure Notification Hub? Should we get the telemetry and store offline if we want to trace a message 7 days later?
Telemetry is retained by the system for 30 days. Also worth noting that notification telemetry is only available when on the Standard SKU.
I see now that this value doesn't appear to be documented. I'll see if I can get the Notification Hubs documents updated to properly reflect this. Thank you for raising the question.
Related
In the past, it was possible to setup an Azure alert on a single event for a resource e.g. on data factory single RunFinished where the status is Failed*.
This appears to have been superseded by "Activity Log Alerts"
However these alerts only seem to either work on a metric threshold (e.g. number of failures in 5 minutes) or on events which are related to the general admin of the resource (e.g. has it been deployed) not on the operations of the resource.
A threshold doesn't make sense for data factory, as a data factory may only run once a day, if a failure happens and then it doesn't happen X minutes later it doesn't mean it's been resolved.
The activity event alerts, don't seem to have things like failures.
Am I missing something?
It it because this is expected to be done in OMS Log Analytics now? Or perhaps even in Event Grid later?
*n.b. it is still possible to create these alert types via ARM templates, but you can't see them in the portal anymore.
The events you're describing are part of a resource type's diagnostic logs, which are not alertable in the same way that the Activity Log is. I suggest routing the data to Log Analytics and setting the alert there: https://learn.microsoft.com/en-us/azure/data-factory/monitor-using-azure-monitor
We've been doing a bunch of bulk fixing of issues in our codebase (deprecated code usage, mostly) and every time the analysis kicks off next, everyone gets 10-100-1000 individual emails detailing the status changes that occurred.
Is there any way to consolidate all this information into a single email so users don't end up being unable to tell what's going on due to sheer bulk of repetitive information?
I really don't want to have to turn off the notification emails and implement my own email mechanism if I've just missed a setting or plugin somewhere.
You can change the user notification subscriptions. Here are the different notifications a SonarQube can set in 6.7:
Background tasks in failure on my administered projects
Changes in issues assigned to me
New quality gate status
Issues resolved as false positive or won't fix
New issues
My new issues
Either keep only “My new issues” or unassign issues that will not be fixed by the author.
There's an issue that is linked to the problem raised. Feel free to vote for it.
I want to integrate github with a external service.
In particular I want certain actions to happen when an issue closes or a milestone is completed. I can see how to do the above for issues by adding a webhook against the issue event updates http://developer.github.com/v3/repos/hooks/.
However, I don't see any events around milestones.
Why is that? Is it an ommission? I have seen some integrations of github milestones with the google calendar - I am assuming that this requires webhooks (I wouldn't expect them to use polling against the milestone api).
One alternative I have thought if there is no such event, is to listen for issue events and every time an issue closes, check whether this issue is associated with a milestone, and if it is check whether all other issues associated with that milestone are already closed and then create my own "milestone completed" event. ( I don't need milestone create events).
Any suggestions would be greatly welcomed.
Yeah, there are no milestone events at this time. Your idea using issue events and checking the milestone closed issues count is probably the way I'd do it too. Remember to use conditional GETs when fetching the milestone info in order to reduce your API quota consumption.
There are now webhook events for milestones - introduced by Github in October 2016. See:
https://developer.github.com/changes/2016-10-27-new-label-and-milestone-webhooks/
I'm evaluating Jopr 2.3.1 to monitor a JBoss 4.2.3 Application Server.
Jopr, based on the better known RHQ Project from Redhat, supports to send email notifications triggered by so called alerts. Alerts can be defined to react to certain changes of system parameter such as metrics (e.g. 'Active Thread Count', 'JVM Free Memory') or the availability (e.g. goes UP, goes DOWN) changes.
I'm now wondering if it's also possible to send a for instance weekly status report by email?
Just to make sure: This email notification is to be send periodically, indipendent of the regular alter notification, rather problems occured or not.
Many thanks in advance - every hint is appreciated
Tobias
RHQ 3 (anything Jopr related is old and outdated) has server side plugins.
They can be alert notification senders that let you e.g. connect to a trouble ticket system for alert notifications.
They can also be more generic and can be triggered periodically via an "internal cron". The latter may be what you want for report sending. In fact, Mazz has already written an example plugin generating a report on file system - you would only need to change the "write to disk" to "send email".
http://rhq-project.org/
I'd like to have something in my app that is just like Twitter but not Twitter. Basically it will be a place people can submit messages and do not need an account. They only way they can submit is through the app. I want other app users to see the submitted messages nearly immediate. I believe push notification can do that sort of work but do I need push notification for this? How does Twitter do it?
-- EDIT --
After reading some of the responses, push might be what I need. People will be submitting messages to my server often. If someone is watching the feed, they might see one new message per minute depending on the query they are using. I'm thinking to go with a MySQL database, (which allows switching to cheaper non Windows servers w/o much hassle) and push notification. Are there any reasons those won't work for my scenario?
You only need push notification if you want the app to be able to receive new messages while closed.
Here's a rough description of one way to do this:
Your app sends a message via HTTP Post to your server.
Your server stores the message in a database, using the iPhones unique ID as an identifier.
Your app connects to the server frequently, asking for new messages.
If there are any new ones, the server hands the message to the app, which displays it.
This is approximately what twitter/iphone twitter apps do.
Your choices are fairly binary:
Use push notification
Use Polling
With Push Notification:
You control when you contact your users... Heavy Load means you can slow updates down to avoid taxing your infrastructure
Contrariwise, you have to push to clients that may not even be there anymore (And thus may need some sort of register model), high load may mean that clients don't get immediate update
You can leverage things like Amazon's EC2 to give you more processing power
Unless you're out of capacity, users are almost certain to be receiving updates as they happen
To pick up messages missed while offline, the SERVER needs to know what message was last successfully received, store older messages and forward many all at once
If you choose to use polling:
You must have a stable address to be polled
You need the ability to have lots of quick query connections checking for new data, then returning that data if required.
If your application becomes popular enough you may find you don't have enough resources
If your resources are taxed your application will go down, rather then just slow down
You don't need to register clients and keep track of their on/offline state
Parallelizing on the fly is a bit trickier
To pick up older messages, the CLIENT needs to know when they last received a message and then request the server send any message since that time
Both can be fast, but they come with different bandwidth and processing profiles. I prefer push for everything that's real-time.
Might want to take a look at XMPP.
Twitter doesn't really push events out to the iPhone in realtime. It's more like polling by the various clients.
If you really want instantaneous for the last mile you'll want to use push.
Twitter uses lots of servers and raid arrays to handle the load of millions of people posting 140 character messages. Twitter clients log in and request a list of updates for all of the people the user is following within a certain time frame.
Push wouldn't be a good candidate for this because it does not persist the "tweets". It is simply a notification mechanism. There is a text messaging app on the App Store (called Ping!) that relies completely on push notification for sending text messages. This seems to work fine, but if the developers are keeping track of the messages, it is all done on their servers. In their case push makes sense as you want to alert the user of a new message. In the case of a twitter clone, however, it would probably just annoy users if they got a new notification every time someone tweeted.
In the end you're better off just implementing it server side and then developing an iPhone client that logs in and retrieves the latest tweets for the people the user is following.