Skip to content

Conversation

@JamesDawson
Copy link
Contributor

Some initial thoughts on progressing the 'dev insights' concept we've talked about.


Cons:
* Price premium compared to purely data storage-based pricing of other options, both for ingestion >5GB/month and retention >90 days
* Potential lag in data being available (potentially mitigated by Live Metrics Stream if supported for this scenario)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree that the delay (circa 5 minutes) can be a frustration. But would you be using this to debug live issues for example whilst getting a CI/CD new pipeline up and running for the first time?

Pros:
* Built-in semantics for tracking events, exceptions etc.
* OOTB visualisation and query tools in the Azure Portal
* .Net SDK reduces up-front integration effort

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pro is it applies the "buy before build" principle?
Another pro is that would extend the concept of a central logging solution for "BuildDevOps", assuming Application Insights is being used already for infrastructure / application telemetry? So opportunity to look at pain points with applications through their end to end lifecycle, not just after they have been deployed?

* Lower costs for long-term retention

Cons:
* Any visualisation interface will need to be built

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots of small events needing to be consolidated in the data lake reminds me of the challenges Ed has been having with SmartR?

* OOTB visualisation and query tools in the Azure Portal
* .Net SDK reduces up-front integration effort

Cons:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Application Insights also drops data if it decides it needs to, which it calls "sampling" IIRC. This is often a useful feature, enabling you to maintain an overview of what's going on without paying to capture every last bit of information. But for this sort of diagnostic logging of a single process, it could be a liability.

I've never been entirely certain if it's possible to completely disable this sampling feature. I know you can ask for it not to happen, but it's not clear to me whether it takes that as an inviolable instruction, or just a suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants