Under step 2 "Not we are installing as root" > "Note…", and "see what the exmple output" > "see what the example output"
Under the ninja section on building your own collector (which I did not test), benefits of building your own collector #1 should just say "small binary sizes" or "smaller-sized binaries".
Under "Considerations for building your own" step 3 "distrobution" -> "distribution".
Not a typo, but the last sentence under the Considerations section implies to me that Splunk does actually support building your own collector – I'd maybe change it to say "Using Splunk's distribution of the OpenTelemetry collector provides a curated experience…" or something.
Under the command box for step 4, "Congratulations!…" has an "OpenTelemtry" there.
In addition to mentioning the Splunk distro being installable from our GH repo, you may also want to say that there's also an easy installation script in the UI, just in case people are feeling overwhelmed.
On page 2-extensions:
The first sentence has an extra "is" ("Now that we have the OpenTelemetry Collector is installed"), also that should end with a comma instead of a period.
In the info box below the zPages section, "If you are not following along you can use your browser you can access a test environment" has an extra "you can" in there -> "If you are not following along you can use your browser to access a test environment"
In the Ninja box on this page, first sentence: "it should so something like" -> "it should do something like" or "it should look something like"
Still in the Ninja box, "you will need to update to include the following" should say what they have to update, so -> "you will need to update /etc/otelcol-contrib/config.yaml to include the following"
Under the Why queue data to disk section, "(and even restart)" is kind of unclear. Maybe say "This allows the collector to weather network interruptions (and even collector restarts) to ensure data is sent to the upstream provider"?
Also under that section "There is a potential that this could impact data throughput performance due disk performance" is missing the 'to' between "due" and "disk"
On page 3-receivers:
The Ninja box's first sentence should say "short-lived tasks".
The Ninja box's link to "enviroment variables" is missing an n
The Ninja box's sentence of "There is only two things needed" should be "There are only two things needed"
At the end of the page do you maybe want to have them restart the collector and verify it's still running (i.e., they didn't hose the config) by having them curl the healthcheck again?
NOT a typo: the config.yaml in the check-in and the config.yaml example above on this page needs to tell the participant to also rename the metrics receiver in the pipeline itself to prometheus/internal to match the change that was made on this page, otherwise the collector does not start. (This was on line 73 of my config.yaml at this point) [OK, I see that this gets fixed on page 6. However, if anyone does restart the collector and try to verify that their changes or YAML syntax are correct, it will break here. Might be worth mentioning that the config is currently incomplete and not to restart the collector yet?]
On page 4-processors:
In the Ninja box, "output of one pipeline to input another pipeline" is missing an "of"
Also in the Ninja box, the following sentence is missing something, maybe "An example of how this is beneficial is that some services emit metrics…"?
Below that in the "Why a connector" section, "oppotunity" is missing an r. Also in that section, the last sentence seems kind of like an orphan - is there meant to be an example there?
On page 5-exporters:
Under the OTLP HTTP Exporter section, the filename is missing a hyphen (and is actually wrong), it should be "/etc/otelcol-contrib/config.yaml".
On page 6-service:
I'd draw attention to the second sentence in the first paragraph. Maybe put it in a box with an alert icon next to it or something. This is a really common mess-up and we should make it clear that you have to define things in two places.
Do you want to insert a 'troubleshooting' box in case the restart fails? Most common is probably going to be bad YAML, so maybe the instances can have a linter installed or something?
The visualization page I assume is a WIP where you'll have people find that dashboard in SOC then filter their attendee name? I'm on board.
On page 1-installation:
On page 2-extensions:
On page 3-receivers:
On page 4-processors:
On page 5-exporters:
On page 6-service:
The visualization page I assume is a WIP where you'll have people find that dashboard in SOC then filter their attendee name? I'm on board.