OpenTelemetry Receiver to Splunk Observability dashboard generator (Terraform configs)

dashboards-and-dashboard-groups/otel-receiver-dashboard-generator/.gitignore

@@ -0,0 +1,195 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#pdm.lock
+#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
+#   in version control.
+#   https://pdm.fming.dev/#use-with-ide
+.pdm.toml
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+.idea/
+
+# Local .terraform directories
+**/.terraform/*
+
+# .tfstate files
+*.tfstate
+*.tfstate.*
+
+# Crash log files
+crash.log
+crash.*.log
+
+# Exclude all .tfvars files, which are likely to contain sensitive data, such as
+# password, private keys, and other secrets. These should not be part of version 
+# control as they are data points which are potentially sensitive and subject 
+# to change depending on the environment.
+*.tfvars
+*.tfvars.json
+
+# Ignore override files as they are usually used to override resources locally and so
+# are not checked in
+override.tf
+override.tf.json
+*_override.tf
+*_override.tf.json
+
+# Include override files you do wish to add to version control using negated pattern
+# !example_override.tf
+
+# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan
+# example: *tfplan*
+
+# Ignore CLI configuration files
+.terraformrc
+terraform.rc

dashboards-and-dashboard-groups/otel-receiver-dashboard-generator/README.md

@@ -0,0 +1,55 @@
+# Generate Splunk Observability Dashboards from OpenTelemetry Receivers
+These scripts help users of OpenTelemetry Receivers from the [OpenTelemetry Collector Contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/) generate Terraform configurations of Splunk Observability dashboards from OpenTelemetry Receiver `metadata.yaml` files that contain the receiver's available metrics.
+
+## Generate dashboard for a single receiver
+Install the requirements and run `otel-dashboard-o11y.py` with the `--file_path` option pointing the `metadata.yaml` file for the receiver you'd like to generate from. 
+
+Note: The Terraform configuration will print to STDOUT which can be piped to a `.tf` file. 
+```
+pip3 install -r requirements.txt
+python3 otel-dashboard-o11y.py --file_path ./metadata.yaml
+```
+
+## Generate dashboards for many receivers
+If the `--file_path` argument is not used the script will look in the local directory [`./otel-receiver-yaml/`](./otel-receiver-yaml/) for available receiver `metadata.yaml` files with metrics sections. Generated Terraform configurations will be placed in the local directory [`./observability-tf-configs`](./observability-tf-configs/).
+
+`pull-otel-yaml.py` can be used to pull down all [receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver) configs with a `metrics` section and place them in the `./otel-receiver-yaml` directory. To avoid api rate limiting during this process a Github PAT token can be provided with the environment variable `$GITHUB_PAT_TOKEN`.
+```
+pip3 install -r requirements.txt
+python3 pull-otel-yaml.py                          
+
+Metadata.yaml with 'metrics' section extracted from activedirectorydsreceiver
+Metadata.yaml with 'metrics' section extracted from aerospikereceiver
+...
+```
+
+## Terraform Configuration Considerations
+**NOTE:** These generated dashboards are not a replacement for any of the Out Of The Box dashboards available in Splunk Observability. [A list of those dashboards is available here](https://docs.splunk.com/observability/en/data-visualization/dashboards/dashboards-list.html). Using the out of the box dashboards will most likely provide the best monitoring experience for a given technology.
+
+Generated Terraform configurations are just that... Generated. They include a line chart per metric named for that metric in a dashboard named for the receiver.
+
+When generating a large number of configs there may be duplicate resource names in `terraform plan` based on metrics that use the same name. In this case edit the duplicate resource name and re-run `terraform plan`
+
+### Terraform `signalfx` Provider
+All generated configs work with the [`signalfx`]() Terraform provider. You'll need to define the provider in a `.tf` file in the same directory as your generated configurations.
+
+**Example Provider configuration:** edit to incude your `api_url` and `$SFX_AUTH_TOKEN` for your specific Observability api url and api token.
+```
+terraform {
+  required_providers {
+    signalfx = {
+      version = "~> 9.0.0"
+      source  = "splunk-terraform/signalfx"
+    }
+  }
+}
+
+# Configure the SignalFx provider
+provider "signalfx" {
+  auth_token = "${var.SFX_AUTH_TOKEN}"
+  # If your organization uses a different realm
+  api_url = "https://api.us1.signalfx.com"
+  # If your organization uses a custom URL
+  # custom_app_url = "https://myorg.signalfx.com"
+}
+```