These should be simple recipes that can be modeled off of our already existing Amazon Linux 2 Recipe. This link will provide the necessary installation instructions. Note: This will require creating recipes for Debian 8, 9, and 10.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-42

The recipe library in this repo serves as the config data store of New Relic integrations. These recipes need to be rolled up and passed to the backend recipe service. We need a workflow that compiles a list of these recipes into a document DB/artifact and initiates a call to the recipe service to update its data cache.

Acceptance Criteria:

• GitHub Actions workflow that generates a build artifact of the recipes
• GitHub Actions workflow/webhook that triggers a refresh of the document store for the recipe service

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-33

GH Pages site, similar to https://newrelic.github.io/nr1-catalog/

We will keep this as a stretch goal.

AC

• Can install all recipes on: NR Staging, EU and Gov region

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-38

This MMF captures necessary enhancements to recipe capabilities to cater to MVP use cases.

On a release action, we need to compile the existing versions of the recipes into one document for consumption by the recipe service. This is likely accomplished with GitHub actions and compiled format that can be parsed and processed into the service that's handling interaction with NerdGraph.

Documentation: https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/apache-monitoring-integration

Necessary Configuration:

• Status URL (prompt user to confirm default value http://127.0.0.1/server-status?auto or enter a new one)

The default status URL works for an OOB apache2 installation.

For Logging: Ensure that common log file directories/patterns & process name for Apache is populated in the beginning of the recipe.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-46

Given a recipe handle and an os, return a recipe.

We need the ability to prompt for user input and provide instructions to write to a NR configuration file based on that user input. This is a common use case for many instrumentation/ integration installations.

Some example use cases:

• Allow user to provide basic necessary configuration information, such as the application name.
• Prompt the user for log files that they'd like to ingest and use it to write appropriate YAML files

Acceptance Criteria: Demonstrate accepting user input by prompting for a log file, and show that log data is coming into New Relic from that log file.

• load the recipe file on PR to main
• create an OS-specific container to execute the recipe
• validate that recipe can execute successfully

These should be simple recipes that can be modeled off of our already existing Amazon Linux 2 Recipe. This link will provide the necessary installation instructions. Note: This issue will require creating recipes for RHEL 8, 7.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-39

Documentation: https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/jmx-monitoring-integration

Necessary Configuration:

• JMX Username: Prompt user to enter
• JMX Password: Prompt user to enter
• JMX Host: Allow user to confirm default of localhost, or enter new
• JMX Port : Allow user to confirm default of 9999, or enter new
• IF user is using Tomcat based on process discovery data
  • Copy the tomcat-metrics.yml.sample file and name it tomcat-metrics.yml to enable
  • Output to the user We have detected you are running Tomcat, the default tomcat-metrics config file has been copied to /etc/integrations.d. NOTE you may need to configure your tomcat JVM to receive JMX Data by setting appropriate CATALINA_OPTS. Please refer to your Tomcat documentation for additional details on how to enable JMX.
• IF user is using JBoss based on process discovery data set jmx_remote to true.
  • Prompt: We have detected JBoss on your system. Would you like to enable the Jboss Connection Format (Y/N) If user selects Y then set jmx_remote_jboss_standalone to true, otherwise set to false.
• Prompt: Are you using SSL?(Y/N) If YES
  • Prompt Enter key store file path if applicable):
  • Prompt Enter key store password if applicable):
  • Prompt Enter trust store file path if applicable:
  • Prompt Enter trust store password if applicable:

Based on these prompts set variables key_store, key_store_password, trust_store, trust_store_password in the config file accordingly.

This particular integration needs to be tested with tomcat, JBoss, and another generic Java service.

For Logging: Ensure that common log file directories/patterns & process name for JMX is populated in the beginning of the recipe.

Sheila 1/7/2021: CC needs to test JBoss, Tom Cat and generic java svc on each distro.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-53

The search UI in NR1 needs to be able to search through frameworks, etc., the recipe needs to account for that.

ex: Django as a search team needs to tie back to the Python recipe(s)

These should be simple recipes that can be modeled off of our already existing Amazon Linux 2 Recipe. This link will provide the necessary installation instructions there today. Note: These recipes should cover CentOS 8 and 7

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-44

The goal of the open install library is to accept external contributions from other stakeholders within New Relic and the community. In order to validate the contributions, we will need a framework for testing the recipes and determining whether they function properly and are able to be released.

The scope of this MMF is to create an early prototype for this framework.

Acceptance Criteria:

• Validate the structure of a recipe through a schema validator/linter
• GitHub Actions workflow that configures a testing pipeline on AWS and runs the appropriate recipe files for Amazon Linux 2 and Ubuntu
• Validation of data flowing into New Relic

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-32

This should be a simple recipe that can be modeled off of our already existing Amazon Linux 2 Recipe. This link will provide the necessary installation instructions there today.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-41

Documentation: https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/cassandra-monitoring-integration.

Necessary Configuration :

• Username: (Prompt user to enter)
• Password: (Prompt user to enter)
• Hostname: (Allow user to confirm default of localhost, or enter new value)
• Port: (Allow user to confirm default port of 9042, or enter new value).

Note: The default cassandra port is different in our docs and base config file, and this is not the default port that Cassandra runs with. We should use the 9042 default in our version of the config file.

For Logging: Ensure that common log file directories/patterns & process name for Cassandra is populated in the beginning of the recipe.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-47

See #16. Build an action to execute.

AC

• Fix whatever is currently not working about the open-install-library recipe
• Update the demo command to
  curl -Ls https://raw.githubusercontent.com/newrelic/newrelic-cli/master/scripts/install.sh | sudo bash && NEW_RELIC_API_KEY=NRAK-... NEWRELIC_ACCOUNT_ID=... NEW_RELIC_REGION=US NEW_RELIC_CLI_PRERELEASEFEATURES=ALLOW newrelic install -c https://raw.githubusercontent.com/newrelic/open-install-library/main/infrastructure/agent/amazonlinux2.yml?token=...
• Run through the demo steps and ensure everything still works

Documentation: https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/hashicorp-consul-monitoring-integration

Display to user: If using ACL, the credentials for the Consul integration must have the following policies: agent:read, node:read, and service:read.

Necessary Configuration for Prompting:

• Hostname: (Have user confirm default of localhost, enter new hostname if desired)
• Port: ( Have user confirm default port of 8500, or enter new).
• Token: Prompt user: _If you're using an ACL Token for authentication, please enter the token: else press [Enter] to continue. _If the user leaves this entry blank by pressing enter, do not populate the token field in the sample YAML file.
• Prompt user,_ Are you using SSL (y/n). _
  • IF YES-
  • Set enable_ssl configuration parameter to true.
  • Prompt User: Would you like to trust the server certificate? (y/n)
  • If Yes- No further action necessary
  • IF No- Prompt user for the ca_bundle_dir or the ca_bundle file by saying: _Please enter the certificate authority bundle directory or file. _
  • If NO- No further action is needed

For Logging: Ensure that common log file directories/patterns & process name for HashiCorp Consul is populated in the beginning of the recipe.

Update from sheila 1/7/2021 - Asking CC to pause on this work. Low priorioty for Virtuosos engineers to help with this.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-52

Given a list of processes and an os, pattern match the process list and retrieve a series recipes for a given OS. Return the series of recipes.

As a recipe is committed to the repo, we need an environment to test the instructions.

This prototype currently relies on hardcoding /var/syslog

Documentation: https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/elasticsearch-monitoring-integration

Necessary Configuration for Prompting:

• Username :(Prompt user)
• Password : (Prompt user)
• Hostname: (Have user confirm default of localhost, enter new hostname if desired)
• Port: ( Have user confirm default port of 9200, or enter new).
• Config Path : (Have user confirm default path of /etc/elasticsearch/elasticsearch.yml, or enter new)
• Prompt user and ask,_ Are you using SSL (y/n). _
  • IF YES- Set use_ssl configuration parameter to true, and prompt user for the ca_bundle_dir or the ca_bundle file by saying: _Please enter the certificate authority bundle directory or file. _
  • If NO- No further action is needed

The way the specific configuration file is structured for elasticsearch, the recipe will need to automatically set the following config parameters to these default values. The remaining optional fields can be kept as is.

• command:all
• cluster_environemnt: staging
• timeout: 30

For Logging: Ensure that common log file directories/patterns & process name for Elasticsearch is populated in the beginning of the recipe.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-49

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-55

Documentation: https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/f5-monitoring-integration

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-50

These should be simple recipes that can be modeled off of our already existing Amazon Linux 2 Recipe. This link will provide the necessary installation instructions. Note: This issue will require creating recipes for SLES 12.4, 12.3, 12.2, 12.1

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-43

Documentation: https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/haproxy-monitoring-integration

Necessary Configuration:

• Username: (Prompt User)
• Password: (Prompt User)
• Stats URL: (Prompt User)

Cluster name and remaining default values should be able to be kept as is in the configuration file.

For Logging: Ensure that common log file directories/patterns & process name for HAProxy is populated in the beginning of the recipe.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-51

For containerized environments, and for language agents that require modifications to source code- customers typically "bundle" agents in within their application. This usually entails making changes to Dockerfiles in addition to modifying source code and dependencies for certain languages.

Requirement Overview : Provide capabilities to interrogate and modify a Dockerfile in order to bundle agents in with a containerized application through the new relic CLI. This tooling will need to be accompanied by CI platform specific guidance or an integration (if possible) to expose the NR license key in a secure manner.

Now I am editing the body in GitHub again.

We need

• execution of shell commands
• variables that can we input from the command line or overridden by flags and/or environment variables
• YAML format
• (ideally) written in Go so that it plugs in seamlessly to the CLI

We've settled on https://taskfile.dev/#/

These should be simple recipes that can be modeled off of our already existing Amazon Linux 2 Recipe.These recipes should cover Ubuntu 18, 16, 14 and 12.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-40

One common, versioned file of all the recipe instructions and related metadata.

When a recipe is PR'd, verify that the contribution can executed successfully using a valid #14.

https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kafka-monitoring-integration

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-54

Documentation

https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/couchbase-monitoring-integration

Necessary Configuration:

• Username :(Prompt user)
• Password : (Prompt user)
• Hostname: (Have user confirm default of localhost, enter new hostname if desired)
• API Port: ( Have user confirm default port of 8091). Note this value is port in the config file.
• Query Port ( Have User confirm default port of 8093)
• Prompt user and ask,_ Are you using SSL (y/n). _
  • IF YES- Set use_ssl configuration parameter to true, and prompt user for the ca_bundle_dir or the ca_bundle file by saying: _Please enter the certificate authority bundle directory or file. _
  • If NO- No further action is needed

For Logging: Ensure that common log file directories/patterns & process name for Couchbase is populated in the beginning of the recipe.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-48

See overall User flow & narrative document for reference.

Prompt the user to choose between auto-discovery or manual specification path.

Auto Discovery Path

Allow auto-discovery option where we leverage the process detector & log detector metadata to auto-detect relevant systemd services and application logs on the host. Auto discovery and detection of log files will be limited in scope to technologies we support within OHIs for the MVP.
**
Manual Specification Path**
The user is prompted for 1) What log files they'd like to ingest and 2) Specify what services on the system they'd like to ingest data from

Using either the auto discovery information or the input specified by the user, we will update the YAML configurations in the logging.d directory with the appropriate files and systemd services.

Note to ClearCode: Ignore this issue, this will be handled internally by New Relic.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-22

Create a one command install that detects the appropriate Linux flavor and executes the proper recipes. This MMF will have two parts:

1. Creating the additional recipes beyond ec2-Linux
2. Developing the auto-detection logic for determining what recipe to run.

Aha! Link: https://newrelic.aha.io/features/VIRTUOSO-21

For containerized environments, and for language agents that require modifications to source code- customers typically "bundle" agents in within their application. This usually entails making changes to Dockerfiles in addition to modifying source code and dependencies for certain languages.

Requirement Overview : Provide capabilities to interrogate and modify a Dockerfile in order to bundle agents in with a containerized application through the new relic CLI. This tooling will need to be accompanied by CI platform specific guidance or an integration (if possible) to expose the NR license key in a secure manner.

We need the ability to prompt for user input and provide instructions to write to a NR configuration file based on that user input. This is a common use case for many instrumentation/ integration installations.

Some example use cases:

• Allow user to provide basic necessary configuration information, such as the application name.
• Prompt the user for log files that they'd like to ingest and use it to write appropriate YAML files