Who here has switched to Log Monitoring v2 and do you like it?
Did you lose functionality?
Do you wish you waited longer? (since you can't revert back)
Any advice for those of us thinking/waiting to switch?
I have one major concern holding us up from switching.
|On-demand access to log files on monitored host||v1: Yes||v2: No|
Our Infrastructure and Application teams heavily use the ability to read the past 500MB or 7 days of Windows system logs and such files by simply accessing them via Dynatrace. This has a been a huge help in troubleshooting issues very quickly (MTTR - I big sales point from Dynatrace). I'm concerned this ability is going to go away. We're a small company with only 1,500 or so servers in Dynatrace but every one of those servers have a Windows System, Windows Event, Windows Security or var/log/messages that is written to frequently. I can't image what the additional charge would be if DT changes their policy on this when we're forced to switch to V2. (similar to when they switched Cloud to DDU, we turned it all off and is no longer seen as a DT value add functionality).
I am working with an endcustomer that has the exact same concern. They are not going to switch to v2 because they dont want to lose the on-demand log and they are not ready to invest in quite high amounts of DDUs that will be required to store the logdata in Dynatrace instead.
agreed with your experience. We're looking to now depart DT as our logging solution. We have other internal options that are now proving to be cheaper, more intuitive, easier to use, and more powerful. Their recent attempts to streamline problems, traces, metrics, and logs is at the moment too little too late.
Dynatrace any feedback on this? Feel like we might have gotten setup here, first Logs were switch to be DDU consumers then it was changed that the original expectations of logs would now be charged. We signed only a year ago, quite a drastic change because our DDU expectations and estimates from original signing our now blown out of the water.
A competitor did something similar and now receives comments such as "logging (bills) without limits!" from its customers. Are we heading the same direction?
We have been running v2 for around 6 months and from the experience we have had, I wouldn't recommend going anywhere near v2 until Dynatrace have ironed out all of the teething problems it introduced for us. Although some of the v1 functionality is still missing within v2, the overall experience via the UI is much better than v1. With v2, you also get the ability to use generic log ingestion via the API which includes the ingestion of Azure logs.
Things to watch out for as part of the migration:
Although my experience of v2 log analytics hasn't been brilliant so far, I do believe Dynatrace are moving in the right direction in terms of their road map. My hope is that they will eventually be in a position to properly compete against other log analytics tools such as Splunk.
Adding two more items per post (https://community.dynatrace.com/t5/Dynatrace-Open-Q-A/Log-Monitoring-v2-Dynatrace-Managed/td-p/17307...)
- I miss the summarize feature - and other things (every log line is now a message - even though the clearly are one log message).
- I hate the fact that I had to upgrade all nodes to 64GB RAM, and this was not mentioned in the documentation.
- Logging v2 missing functionality previously in v1 and may now require you to setup additional tools.
- Logging v2 is splitting multiple line logs into multiple messages making it difficult to analyze
Two more customer complaints that V2 removes the ability to download/pull logs from hosts.
Field extraction breaks in v2. Impact to graphs that used to work with v1.
We are considering switching to v2 mainly because of the K8s event monitoring feature - which seems to require it (sadly)...
We are currently on Managed and our 3 nodes already have 96GB of RAM and 8 CPU's as well as attached dedicated Elasticsearch storage of 100GB each.
Besides pros/cons that have already been mentioned in this topic there are a couple more things I would like to confirm/understand before we decide to take the plunge or not:
I would be grateful for any input.
There are pros and cons. Maybe I can't anwer for your all questions.
There are some advanage of the v2, I thnik the speed of filtering is quite fast becasue of the Elastic, I love the view trace frunction when relevant logs are connected to the trace (at distributed traces), SRE and developers find the required logs very quickly.
I hope it helps.
Thanks a lot @Mizső.
Regarding #2: I just found this page in the documentation:
So it seems that starting with 1.252 any configured log sources under v1 are automatically migrated to v2 as "matchers" under either the host or tenant scopes and therefore won't have to be re-added manually... Would be great if anybody could confirm this.
But still, that means we would have to re-configure log metrics and log events from scratch in order to get the same log monitoring with v2.... Considering the amount of settings involved in our current environment this looks like a show-stopper to me....
I just received further feedback from support regarding #2: With 1.252+ there will be two log storage configuration options - old and new. While the new storage option (as outlined here) will be available as an "opt-in" the old log sources config will continue to work as the default - so apparently no manual migration will be needed to re-add log sources to monitoring after enabling LMv2.
I suspect the new storage config is designed to tie-in with the brand new Grail™ "data lakehouse" offering...