An Incidence Response (IR) Knowledge Graph lets you query the current system and find events that led to its current state.
Most engineering teams today use multiple tools that need to be consulted to understand the system. Having so many disparate stores fractures system understanding. This handicaps human Incident Responders, discourages automated response and prolongs incidents.
IR Knowledge Graphs centralize information from disparate sources in order to provide a sane view into system state while maintaining system structure and exposing it for analysis.
fluxroll helps you build an Incident Response knowledge graph
Step 1: Instrument your deployment scripts
The first step in the process is to instrument your deployment scripts. You need to add a line so that fluxroll is notified of any deployment being made.
curl -X POST https//{api_key}@{your_org}.fluxroll.com/api/deployments/
-F artifact='fluxroll.com'
-F version='d9b96b01'
-F message='Added interactions callback'
-F environment='production'
Essentially you’re sending fluxroll:
- Artifact (service/application) name
- Git SHA/version
- A message describing the nature of the change
- The environment being affected
Fluxroll records each deployment event and can also notify you of the deployments on Slack.
Because we track deployments and integrate with all the major git providers, we can show you what changed between deployments. No need to look at commit histories or tags to figure out what changed anymore. Just click the “See Change” button.
PRO-TIP: Our API lets you programatically add artifacts on fluxroll so you don't have to enter this data manually.
Step 2: Add dependencies
By instrumenting your deployment scripts, your organization can now access a time-series of change events and drill into those events to see the nature of the changes.
This is already extremely powerful but let’s take things a step further. Let’s add dependencies! Fluxroll allows you to easily describe the dependencies between your artifacts. Not only is this useful for everyone to understand how the entire system works, but it also helps during incident resolution.
Besides, maintaining a global event feed, fluxroll also maintains an event feed for each artifact. This feed only contains changes that apply to the artifact you are examining.
For instance if a web-service depends on a database and someone changes the configuration for the database, the change event would show up in the feed for both the database and the web-service. This makes diagnosing problems super easy as you have all the change information laid out for you in a central location.
Don't have any idea of what your dependencies are?
Don't fret. This is a common for many of the companies that we’ve worked with. There are two options:
- You can add dependencies manually as you discover them. This works at companies where the infrastructure is fairly stable i.e services rarely get added and dependencies don’t change too often.
-
For more dynamic environments, our suggestion is to use Open Telemetry
to trace service hops and then feed that data back to fluxroll. We have APIs that allow you to modify dependencies programmatically and are working on a tool that pulls dependency information from traces.
Step 3: Document your artifacts
Teams today use a whole suite of tools for monitoring and logging various aspects of the systems. Fluxroll has easy to define templates that you can use to document and link to these systems. No need to remember how to query your logging tool to see relevant logs. No need to remember, where errors are being tracked or how to access that information. It’s all there for you in one place.
