cwielenb/CNCF-Dataset huggingface dataset:
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: mixpanel.md

title: Mixpanel Analytics Integration description: Integrate Flagsmith with Mixpanel sidebar_label: Mixpanel hide_title: true You can integrate Flagsmith with Mixpanel. The integration automatically sends the flag states for identified users into Mixpanel for cohort analysis, A/B testing and more. The process is as follows: Get the Mixpanel Project Environment ID for your Mixpanel project from the Mixpanel Manage Project page (Project Settings > Project Token) Add the Project Token into Flagsmith (Integrations > Add Mixpanel Integration) All API calls generated by the Flagsmith SDK to the `Get Identity Flags` endpoint will send the a full set of flag evaluations for that particular user to Mixpanel as a :::tip For flags that contain remote config values, Flagsmith will pass the value of the flag to Mixpanel if the flag is `enabled`. If the flag has no remote config value, Flagsmith will just pass the boolean state for the flag. ::: Identity flag values are passed into Mixpanel. If we make the call to the Flagsmith API to get the flags for an Identity: ```bash curl 'https://edge.api.flagsmith.com/api/v1/identities/?identifier=developmentuser123456' \ -H 'x-environment-key: 8KzETdDeMY7xkqkSkY3Gsg' ``` And then take a look in our Mixpanel dashboard, you can see the user and the flag data that has been sent to the Mixpanel platform. Once the integration has been set up, you can start segmenting your Mixpanel identities based on the flags that they saw. This means you can run AB tests driven by Flagsmith segments, and have the data show up automatically in Mixpanel. You have to identify users on both platforms in the same way. The Flagsmith `Identity ID` must be the same as the Mixpanel `identity`. Every time an `Identity` requests their flags from the Flagsmith API, Flagsmith will send a `POST` to `https://api.mixpanel.com/engage#profile-set` with the following JSON payload: ```json { "$token": "<YOURMIXPANELPROJECT_TOKEN>", "$distinctid": "<FLAGSMITHIDENTITY_ID>", "$set": { "<FLAG1ID>": "<FLAG1STATE>", "<FLAG2ID>": "<FLAG2STATE>", "...": "..." } } ``` If you want to control Flagsmith Flags based on Cohorts in Mixpanel, you will need to send cohort data from Mixpanel into Flagsmith. There is no way currently of automating this process from the Mixpanel side, but you can send cohort data from MixPanel into Flagsmith, using . The flow looks like this: Identity cohort changes in Mixpanel -> Triggers MixPanel Webhook -> Hits endpoint on your infrastructure -> You trigger a request to Flagsmith to set traits This Webhook will be triggered by Mixpanel as Identities/Users enter or leave Mixpanel cohorts. We can use this trigger to copy the relevant data from Mixpanel into Flagsmith. Set up a webhook that accepts Mixpanel cohort data as described , then write the cohorts as Traits within the relevant Identities. You can send Trait data either using our SDKs or with a REST query as defined in our .
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-user_create.md

category: User apiurl: '/api/v1/user/create' title: 'Create User' type: 'POST' sample_doc: 'user.html' layout: default Required ```{"name": "test","password": "test", "email":"xxx@xxx.com", "cnname": ""}``` ```Status: 200``` ```{ "name": "owltester", "password": "mypassword", "cnname": "", "email": "root123@cepave.com", "im": "44955834958", "phone": "99999999999", "qq": "904394234239" }``` For more example, see the . For errors responses, see the .
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.3.4.md

Upgrade Jackson-databind to 2.13.2 resolving ) Upgrade netty to 4.1.79.Final resolving ) Upgrade tukaani:xz from 1.9 in plugins/ingest-attachment () Upgrade Tika (2.1.0), xmlbeans (3.1.0), Apache Commons-IO (2.11.0), and PDFBox (2.0.25) in plugins/ingest-attachment () Fix bug where opensearch crashes on closed client connection before search reply. ()
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: RELEASE.md

To release a new version of the project you need to follow the following steps: Create a new branch for the release (e.g., `release/vX.Y`) Create the tag for the release (e.g., `vX.Y.Z`) Push the release branch and tag to the remote Create a GitHub label for backports: ```gh label create "backport release/vX.Y" -d "This label will backport a merged PR to the release/vX.Y branch" -c "#0052cc"``` [!IMPORTANT] The release branch should only contain the major (X) and minor (Y) version, but not the patch level (Z), for example: Correct: `release/v1.3` Incorrect: `release/v1.3.0` The CI will automatically handle the build and create a draft GitHub release. Once ready, you can edit and publish the draft release on GitHub. You will need to take the release notes and append them to the `CHANGELOG.md` file in the root of the repository. The list of changes from the CHANGELOG.md file form the basis of the public-facing release notes. Release notes are added to the . These release notes follow the same pattern for each release: Copy the previous release's page (i.e., V1-3.md) to the new release number. Change the version information and page weight in the file's frontmatter. Update the page title (Version x.x release notes) and add a few sentences about the main updates in the release. Features and enhancements section with list of updates (optional) Breaking changes section with a list of these changes and their impact (this section can also be used to update the ). Bug fixes section with a list of updates. Documentation updates section with a list of updates. For help writing release notes, refer to the . Please do not delete GitHub releases that were once public. To release a minor version simply merge fixes to the release branch then create and push a new tag. (e.g. `v0.x.1`) For helm charts, you need to merge a PR that bumps the chart version in the main branch (no tagging required), the ci will automatically publish the chart to the . The release process uses and can be configured using the . To create a new release first prepare the release using: ```bash make release/prepare ``` This will build and packages all artifacts without pushing or creating the GitHub release. Once you're ready you can then tag your release. ```bash git tag v0.1.0 ``` And finally push the release using: ```bash make release ``` Make sure to have a `GITHUB_TOKEN` correctly set. Make sure to create the release notes and CHANGELOG for any manual release.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: pravega.md

is an open source storage system implementing Streams as a first-class primitive for storing/serving continuous and unbounded data. Pravega organizes data into Streams. A Stream is a durable, elastic, append-only, unbounded sequence of bytes having good performance and strong consistency. Pravega Streams are based on an append-only log data structure. By using append-only logs, Pravega rapidly ingests data into durable storage. Pravega is a distributed system and is deployed on our custom build of Kubernetes having the desired set of microservices, hence we were seeking a tool which can adapt in our environment with minimal alteration and be able to inject faults while exercising quality tests on our product. Therefore, we chose Litmus Chaos to meet our use cases. The benefits we see in Litmus Chaos are: it is a CNCF project, it supports kubernetes type deployment environment, it has frequent & steady releases, and it's a well maintained tool. On deploying Litmus Chaos along with its Chaos Experiments, we get standard fault injection scenarios like: pod-network-loss, pod-network-latency & pod-cpu-hog, which we introduce on live deployments of a Pravega cluster. This helps us to simulate real time stressful conditions on the setup and to test for its recovery & fault-tolerance behavior, which in turn helps us to improve the overall quality of our product in stable as well as adverse conditions.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: openebs.md

OpenEBS is the most active Container Attached Storage project in Kubernetes world. OpenEBS enables the DevOps teams to have their dedicated storage policies for each workload and it is completely Kubernetes native. It provides different storage engines such as , , which could be chosen according to the user's storage requirements. In OpenEBS E2E testing, We realised that functional testing alone is not sufficient to ensure the resiliency of the system. So, We planned to practice chaos engineering in our E2E test suite in order to validate the system's resiliency. We wanted to induce chaos not only specific to OpenEBS components but also on the underlying Kubernetes components which forms the skeleton for Containers infrastructure. Litmus eases our vision by providing chaos charts for the above said components. Litmus has a separate chaos category for OpenEBS charts which is evolving continuously. In OpenEBS E2E, we use GitLab for CI operations. The and chaos charts provided by litmuschaos are incorporated into E2E pipelines which are being executed through GitLab. The OpenEBS E2E tests are executed against various flavours of Kubernetes such as OpenShift, D2IQ Konvoy, Rancher and native plaform as well. So, we use litmus chaos chart in all those platforms to ensure the resiliency of OpenEBS system. The test results are represented via UI portal called Apart from E2E pipelines, we use litmus chaos charts in our soak testing suite where the charts are executed at random intervals. After incorporating the chaos charts into our E2E test pipelines and soak testing environment, the hidden resiliency issues were detected. When we execute the charts at random intervals along with functional test scenarios, the corner cases are getting covered which brings out the resiliency issues.
Project: Botkube (Observability and Analysis / Observability)
File: botkube_telemetry_enable.md

title: botkube telemetry enable Enable Botkube telemetry ``` botkube telemetry enable [flags] ``` ``` botkube telemetry enable ``` ``` -h, --help help for enable ``` ``` -v, --verbose int/string[=simple] Prints more verbose output. Allowed values: 0 - disable, 1 - simple, 2 - trace (default 0 - disable) ``` - Configure collection of anonymous analytics
Project: Netdata (Observability and Analysis / Observability)
File: httpcheck_web_service_unreachable.md

The Netdata agent monitors your HTTP endpoints. You can specify endpoints the Agent will monitor in the Agent's Go module under `go.d/httpcheck.conf`. If your system fails to connect to your endpoint, or if the request to that endpoint times out, then the Agent will mark the requests and log them as "unreachable". The Netdata Agent calculates the ratio of these requests over the last 5 minutes. This alert is escalated to warning when the ratio is greater than 10% and then raised to critical when it is greater than 40%. To troubleshoot this error, check the following: Verify that your system has access to the particular endpoint. Check for basic connectivity to known hosts. Make sure that requests and replies both to and from the endpoint are allowed in the firewall settings. Ensure they're allowed on both your end as well as the endpoint's side. Verify that your DNS can resolve endpoints. Check your current DNS (for example in linux you can use the host command): ``` host -v <your_endpoint> ``` If the HTTP endpoint is suppose to be public facing endpoint, try an alternative DNS (for example Cloudflare's DNS): ``` host -v <your_endpoint> 1.1.1.1 ```
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: ruby.md

title: "Ruby" menuTitle: "Ruby" description: "Instrumenting Ruby applications for continuous profiling." weight: 50 aliases: /docs/phlare/latest/configure-client/language-sdks/ruby The Ruby Profiler revolutionizes performance tuning in Ruby applications. Integrated with Pyroscope, it offers real-time performance data, allowing developers to delve deep into their Ruby codebase. This tool is essential for identifying performance issues, optimizing code efficiency, and enhancing the overall speed and reliability of Ruby applications. {{< admonition type="note" >}} Refer to for a list of profile types supported by Ruby. {{< /admonition >}} To capture and analyze profiling data, you need either a hosted Pyroscope OSS server or a hosted (requires a free Grafana Cloud account). The Pyroscope server can be a local server for development or a remote server for production use. Add the `pyroscope` gem to your Gemfile: ```bash bundle add pyroscope ``` Add the following code to your application. If you're using Rails, put this into `config/initializers` directory. This code will initialize the Pyroscope profiler and start profiling: ```ruby require 'pyroscope' Pyroscope.configure do |config| config.application_name = "my.ruby.app" # replace this with some name for your application config.server_address = "http://my-pyroscope-server:4040" # replace this with the address of your Pyroscope server end ``` The Pyroscope Ruby integration provides a number of ways to tag profiling data. For example, you can provide tags when you're initializing the profiler: ```ruby require 'pyroscope' Pyroscope.configure do |config| config.application_name = "my.ruby.app" config.server_address = "http://my-pyroscope-server:4040" config.tags = { "hostname" => ENV["HOSTNAME"], } end ``` Or you can dynamically tag certain parts of your code: ```ruby Pyroscope.tagwrapper({ "controller": "slowcontrolleriwanttoprofile" }) do slow_code end ``` By default, if you add Pyroscope to a Rails application it will automatically tag your actions with a `action="<controllername>/<actionname>"` tag. To disable Rails auto-instrumentation, set `autoinstrument_rails` to `false`: ```ruby Pyroscope.configure do |config| config.autoinstrument_rails = false end ``` ```ruby require "pyroscope" Pyroscope.configure do |config| config.application_name = "example.ruby.app" config.server_address = "<URL>" config.basicauthusername='<User>' config.basicauthpassword='<Password>' end ``` To configure the Ruby SDK to send data to Pyroscope, replace the `<URL>` placeholder with the appropriate server URL. This could be the Grafana Cloud URL or your own custom Pyroscope server URL. If you need to send data to Grafana Cloud, you'll have to configure HTTP Basic authentication. Replace `<User>` with your Grafana Cloud stack user and `<Password>` with your Grafana Cloud API key. If your Pyroscope server has multi-tenancy enabled, you'll need to configure a tenant ID. Replace `<TenantID>` with your Pyroscope tenant ID. Check out the following resources to learn more about Ruby profiling: showing Ruby example with tags
Project: Botkube (Observability and Analysis / Observability)
File: discord-help.golden.md

Basic commands `@Botkube ping` - ping your cluster and check its status `@Botkube list [source|executor|action|alias]` - list available plugins and features `@Botkube ping` `@Botkube list sources` `@Botkube list executors` Notifications `@Botkube [enable|disable|status] notifications` - set or query your notification status `@Botkube edit sourcebindings` - select notification sources for this channel `@Botkube enable notifications` `@Botkube disable notifications` `@Botkube status notifications` Run kubectl commands (if enabled) `@Botkube kubectl help` Multi-cluster mode If you have multiple clusters configured for this channel, specify the cluster name when typing commands. ``` --cluster-name=Stage US ``` Other features Automation: https://docs.botkube.io/usage/automated-actions Give feedback: https://feedback.botkube.io Read our docs: https://docs.botkube.io Join our Slack: https://join.botkube.io Follow us on Twitter/X: https://twitter.com/botkube_io
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-0-6.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.0.6 <!-- Auto generated by update changelog github action --> Alerting: Add annotation upon alert state change. , Alerting: Allow space in label and annotation names. , InfluxDB: Improve legend labels for InfluxDB query results. , Alerting: Fix improper alert by changing the handling of empty labels. , CloudWatch/Logs: Reestablish Cloud Watch alert behavior. , Dashboard: Avoid migration breaking on fieldConfig without defaults field in folded panel. , DashboardList: Fix issue not re-fetching dashboard list after variable change. , Database: Fix incorrect format of isolation level configuration parameter for MySQL. , InfluxDB: Correct tag filtering on InfluxDB data. , Links: Fix links that caused a full page reload. , Live: Fix HTTP error when InfluxDB metrics have an incomplete or asymmetrical field set. , Postgres/MySQL/MSSQL: Change time field to "Time" for time series queries. , Postgres: Fix the handling of a null return value in query results. , Tempo: Show hex strings instead of uints for IDs. , TimeSeries: Improve tooltip positioning when tooltip overflows. , Transformations: Add 'prepare time series' transformer. ,
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: klanik.md

Founded in December 2011, has built its success on its award-winning Consultant-Centric approach, defining us as a great place to work. #Happyatwork2021 This model is materialized by unprecedented personal and professional development programs: We wanted a tool that we could leverage to test the containerized control plane of our clients public, private & hybrid cloud. When we came across Litmus, we wanted to give it a try. ... To be continued ;) <!-- - It is designed for Kubernetes workload It has wide variety of generic test cases for Kubernetes workload and Infrastructure It can be used to trigger customized validations It is easy to Integrate with our existing automation framework We explored Litmus to validate the resiliency of our private telco cloud by covering the following areas. Testing resiliency of Control plane Kubernetes Infrastructure Validating the HA of different control plane services Testing inter dependency among different open source applications Litmus has has a wide variety of generic test cases for Kubernetes workload and Infrastructure and provides a very easy way for end-to-end automation of resiliency test cases. -->
Project: Checkmk (Observability and Analysis / Observability)
File: 16333.md

key | value | date | 2024-02-01T16:48:01+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | no Sometimes the Lancom routers don't provide a name. During data parsing this caused the description to be left as an empty string. As a result of that, when the router description was configured to be used for the Service Desciption, the discovery did not work properly. This has now been fixed by having a fallback mechanism. If the router name is not present, the router description will be used. Because of the change, the user is required to execute the service discovery again in order to discover any new services. As well as get rid of any vanished services.
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-23-datadog-logs-sink.md

date: "2020-04-13" title: "New Datadog Logs Sink" description: "Sink logs to the Datadog logging service" authors: ["binarylogic"] pr_numbers: [1832] release: "0.9.0" hideonrelease_notes: true badges: type: "new feature" domains: ["sinks"] sinks: ["datadog_logs"] In addition to our , we've introduced a new . This is part of our broader effort to expand Vector's integrations.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: autocomplete.md

sidebar_position: 20 title: Auto-complete description: Flag configuration auto-complete GO Feature Flag offers a way to have auto-completion while creating a flag file. To achieve this we publish a `jsonschema` on . The store is used by all major IDEs such as `vscode`, `intelliJ`, and others. To enable it, you just have to use the extension `.goff.yaml` for your configuration file, and it will be automatically available for you (example: `flag.goff.yaml`).
Project: Vector (Observability and Analysis / Observability)
File: 2021-08-24-helm-vector-dev.md

date: "2021-08-24" title: "Introducing helm.vector.dev" description: "A new home for Vector's Helm charts" authors: ["spencergilbert"] pr_numbers: [] release: "0.16.0" hideonrelease_notes: false badges: type: "deprecation" platforms: ["helm"] Vector's new home for helm charts is at https://helm.vector.dev! We made this change as part of migrating the helm charts from our old AWS S3 bucket hosting to GitHub Pages via . This new domain will also allow us to swap hosting in the future without any user impact. Vectors 0.16.x release will be the last version that publishes charts to both https://packages.timber.io/helm/latest and https://packages.timber.io/helm/nightly repositories. The new repository contains all released charts from the previous `latest` repository. Moving forward we will be releasing charts at their own pace as we work towards the stable releases for the vector-agent and vector-aggregator charts. Development and issue tracking will be migrated to https://github.com/vectordotdev/helm-charts in the coming days. The new repository can be added with: ```shell helm repo add vector https://helm.vector.dev helm repo update ``` Once added the vector-agent chart can be installed with: ```shell helm install vector vector/vector-agent \ --namespace vector \ --create-namespace \ ``` Or upgraded with: ```shell helm upgrade vector vector/vector-agent \ --namespace vector \ --reuse-values ```
Project: Cortex (Observability and Analysis / Observability)
File: CHANGES.md

bump protobuf dep to v1.33 () () v2/callctx:* fix SetHeader race by cloning header map () () add XGoogFieldMaskHeader constant () () v2/callctx:* add new callctx package () () v2:* add BuildHeaders and InsertMetadataIntoOutgoingContext to header () () v2:* add GoVersion package variable () () v2:* handle space in non-devel go version () () update dependencies () () v2:* drop cloud lro test dep () (), refs apierror:* add method to return HTTP status code conditionally () (), refs add ref to usage with clients () (), refs v2:* add WithTimeout option () () v2/apierror:* return Unknown GRPCStatus when err source is HTTP () (), refs update google.golang.org/api to latest () () v2/apierror:* add apierror.FromWrappingError () () v2:* copy DetermineContentType functionality () () v2:* resolve bad genproto pseudoversion in go.mod () () add ExtractProtoMessage to apierror () () v2:* add OnHTTPCodes CallOption () () v2/apierror:* use errors.As in FromError () () v2:* bump release-please processing () ()