If you are familiar with Sentry, one of the leading vendors of application performance monitoring software, then you may also be aware of the quandary they recently faced when rolling out an update to their Terms of Service. Under the terms of the update, Sentry would begin to ingest users' (anonymized) event data into their machine learning system. A small number of users objected to this on various grounds. Some were unhappy at the lack of an opt-out, others expressed concerns around issues such as PII, governance and residency. To their credit, Sentry, reconsidered and decided to postpone the rollout of the new policy until these concerns were allayed.
Some users took to social media to express their discontent and discuss jumping ship to alternative vendors. At this point, however, something of a reality check kicked in. Users who were mooting the prospect of migrating to some other highly respected providers had cold water poured over their plans by the revelation that those companies already have similar clauses enshrined in their own ToS.
To some extent, Sentry were victims of their own transparency. Rather than being an outlier, they were simply following suit with other vendors in the sector - perhaps their only crime was actually being more up-front about the policy than some other players in the IT industry. The dilemma for Sentry was that their pre-existing conditions were less expansive than those of their competitors, but when they fell into line, they risked antagonising a segment of their customer base. In fact, it turned out that the numbers were small - but inevitably their protests were amplified in the echo chambers of social media.
Ultimately, this is not just an issue about the ToS of one vendor, it is a quandary that might be faced by any vendor. Today, some of a company's users may wish to ring-fence their data, tomorrow those same users may look jealously at ML-powered features in competitors' products. From a functional and practical point of view it seems undeniable that applying ML to logs will bring benefits to the whole market. By mining for patterns in large data sets, analytics engines will have improved capabilities for predicting potential outages and will be able to correlate across other systems to offer potential solutions. The technologies will also enable more powerful and sophisticated anomaly and intrusion detection.
At the same time though, if customers have concerns, they can't be dismissed out of hand as over-caution or excessive paranoia. So, what are these concerns, and do they stand up to scrutiny? One of the major concerns is over PII. Theoretically, it should not make its way into logs - but, in reality, it does. Given that any such PII would already be stored in the vendor's data centre, what are the additional risks of applying ML to that data? Issue one concerns potential leakages in transferring the data between endpoints or in the storage used by the ML system. There are more potential points of egress and a larger attack surface.
The second possibility is that of regurgitation. That is to say, the possibility of source data somehow being reproduced in a recognisable way in the tools which have been trained on the ML data. On the face of it, this concern would seem to be misplaced. The purpose of the ML training on data such as application or machine logs is to improve diagnostics rather than to generate new content. The end product of the analytical process will be statistical rather than textual. Many vendors already have the capability to identify and scrub PII. Obviously, these features do have limitations. They tend to focus on easily recognisable patterns such as IP addresses or API Keys and may not be able to identify personal information in blocks of text. Equally, vendors may actually apply an additional charge for these features.
The third objection is on the grounds of principle. The data belongs to the customer and is being entrusted to the vendor for a particular purpose. There is a sense of impropriety around the vendor assuming rights over that data - a kind of breach of that implicit trust. This raises the question of 'fair use' of data in ML and AI systems - and the legal position on this is now being tested in the court's with the OpenAI law suit. In fact, if we zoom out and look at the bigger picture, ingesting log files barely registers as a misdemeanour compared to the industrial scale dredging of personal data being carried out by some of the tech giants. For example, this upgrade for Google Messages will read and analyse your personal message history - with your data being processed in the Google cloud rather than on your device. Meanwhile, this dispute over an AI simulation of deceased US comedian George Carlin also raises complex issues of ethics and ownership. There are of course, myriad other cases one could cite, such as Reddit signing over its user-generated content or GitHub hoovering up code committed to its public repositories.
Such is AI's hunger for real world data that there is speculation that the LLM's will soon "run out of internet". One possible solution to this is the use of synthetic data. This however still involves challenges since feeding successive generations of synthetic data into an LLM can lead to progressive degradation of quality and the danger of model collapse.
It seems like we are, at the moment, in uncharted territory and just beginning the journey towards establishing frameworks and guidelines. So, what might be the standards which could create a level playing field for ensuring good practice across the sector whilst also giving reassurance to customers? The following might represent a starting point:
In conclusion, there is clearly a need for a balance to be struck. A balance between concerns around governance on the part of the client and the desire for innovation on the part of the vendor. At present it seems that some of the very largest corporations in the world are able to gain an advantage by mobilising legal and other resources to stretch the limits of the 'fair use' defence. There clearly needs to be a more consensual and rigorous basis for the mass ingestion, storage and analysis of customer data. We have seen a large number of stakeholders come together to collaborate in the OpenTelemetry project. Perhaps the relationships formed in that effort could be built upon to form an advisory body on industry standards.
Stories about Uber architecture always seem to be interesting, not least because they always involve technology at huge scale - such as this trillion record migration from DynamoDB. This article, however, is actually interesting on a number of levels. As well of being of technical interest it also provides some fascinating insight into internal team topologies and management processes - which are also fundamentally important aspects of managing observability at scale. Whilst most organisations will only operate at a fraction of Uber’s scale, every organisation is seeking to minimise costs and improve service to users, and the article provides a number of insights which would be of interest to most observability practitioners.
A survey carried out by McKinsey in 2021 found that 57% of respondents were already using Machine Learning to support at least one business function. ML is no longer a niche concern but is becoming a core component of development and CI/CD practices. As this post from the Datadog blog notes, the efficacy of ML models will inevitably degrade over time, so monitoring their performance and reliability is critical. The article really drives home the point that ML is a domain with its own specific behaviours, and effective monitoring requires building out new processes, metrics and even infrastructure to cover issues such as Data Drift, Prediction Drift and Concept Drift. Whilst the article does use some specialist terms, it is a highly readable and practical guide to the subject of ML monitoring.
It sounds like it could be a sub-plot in the film Inception, but this is a really interesting article from the Observe blog on how they use an instance of their Observe system to monitor their Observe cloud platform. Observe not only have to support fast reads for complex user queries, they also have to support ingesting one petabyte of telemetry per day. As you can see from the above diagram, Kafka and Snowflake form two of the pillars of the backend architecture. This three-part series offers a fascinating insight into Observe’s own internal observability strategy as well as being a great exemplar of the eat your own dog food principle. This is an article which is of great value to anybody with an interest in large-scale observability architectures.
Most of us have experienced the anguish of bill shock at some point. Being hit with a huge bill for mobile roaming charges on return from your holiday or getting a penalty notice for an inadvertent motoring infringement that happened weeks back. Those are just small pinpricks though, compared to the 50,000 volts of financial burn felt by companies mentioned in this transcript of a scintillating talk by Erik Peterson, CEO of CloudZero. He argues, persuasively, that engineering decisions are buying decisions. In the case mentioned in the headline, a decision to turn on one section of debug code led to vast volumes of logs being emitted and racking up over $1m in costs.
This is a really engaging blog post by Infrastructure Engineer Jack Lindamood, where he reviews nearly every infrastructure decision he made over four years working at a start-up. Each choice is graded with a Regret, Endorse or an occasional Unsure. Whilst not explicitly observability-related, it will however, have resonance for any engineer forced to make technological choices (which is probably all of us). The article contains much distilled wisdom and some strong opinions, as well as general observations on the challenges and trade-offs faced by infrastructure engineers.
The RAG pattern has really gained traction over the past year as it allows enterprises to leverage the power of LLM's to gain insights into their own data. This is a fascinating and (occasionally technical) article which details how Incident IO used vector embeddings to mine through their data and discover related incidents. The article explains the techniques involved with great clarity and provides really helpful advice on creating embeddings to find hidden patterns in your own data.
When you think of large corporations pushing the technology envelope, Chik-Fil-A might not be the first name to come to mind. However, the highly distributed nature of their infrastructure presents massive observability challenges, which they have met with some very impressive engineering. The scale of their task is daunting - 2,800 Edge Kubernetes clusters, tens of thousands of IoT devices and billions of MQTT messages each month. This is a really fascinating article on managing IoT observability at scale.
In this blog article, Bijit Ghosh of Deutsche Bank discusses best practices for observability across the full AI system lifecycle. He composes a custom system which knits together a range of technologies including structlog, Flask, Prometheus and Kibana as well as AI-specific tools such as MLFlow and CausalML. It’s a comprehensive article which exhibits a clear understanding of both observability and AI technologies.
A great example of managing the complexities of Observability engineering. Jay Taylor from InfluxDB builds out a solution using the Telegraf, InfluxDB, Grafana stack.
An in-depth look at monitoring K8S with the increasingly popular VictoriaMetrics platform. This follows an end-to-end process from crafting your own Helm chart to configuring alert rules.
This has really raised a few eyebrows. A forensic analysis by Nikolay Sivko of coroot on how just a few OpenTel meta tags can potentially explode your ingestion fees.
Comments on this Article