feat: add support for viya4-monitoring

CONTRIBUTING.md

@@ -6,14 +6,49 @@ We just ask that you follow our contribution guidelines when you do.
 Contributions to this project must be accompanied by a signed [Contributor Agreement](ContributorAgreement.txt).
 You (or your employer) retain the copyright to your contribution; this simply grants us permission to use and redistribute your contributions as part of the project.
 
-## Code reviews
-All submissions to this project—including submissions from project members—require review.
-Our review process typically involves performing unit tests, development tests, integration tests, and security scans using internal SAS infrastructure.
-For this reason, we don’t often merge pull requests directly from GitHub.
+## Code Reviews
+All submissions to this project—including submissions from project members—require
+review. Our review process typically involves performing unit tests, development
+tests, integration tests, and security scans.
 
-Instead, we work with submissions internally first, vetting them to ensure they meet our security and quality standards.
-We’ll do our best to work with contributors in public issues and pull requests; however, to ensure our code meets our internal compliance standards, we may need to incorporate your submission into a solution we push ourselves.
+## Pull Request Requirement
 
-This does not mean we don’t value or appreciate your contribution.
-We simply need to review your code internally before merging it.
-We work to ensure all contributors receive appropriate recognition for their contributions, at least by acknowledging them in our release notes.
+### Conventional Commits
+All pull requests must follow the [Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/)
+standard for commit messages. This helps maintain a consistent and meaningful
+commit history. Pull requests with commits that do not follow the Conventional
+Commit format will not be merged.
+
+### Developer Certificate of Origin Sign-Off
+This project requires all commits to be signed off in accordance with the [Developer Certificate of Origin (DCO)](https://developercertificate.org/).
+By signing off your commits, you certify that you have the right to submit the
+contribution under the open source license used by this project.
+
+To sign off your commits, use the --signoff flag with git commit:
+
+```bash
+git commit --signoff -m "Your commit message"
+```
+
+This will add a Signed-off-by line to your commit message, e.g.:
+
+```bash
+Signed-off-by: You Name <[email protected]>
+```
+
+For more information, please refer to https://probot.github.io/apps/dco/
+
+### Linter Analysis Checks
+All pull requests must pass our automated analysis checks before they can be
+merged. These checks include:
+
+- **Hadolint** – for Dockerfile best practices
+- **ShellCheck** – for shell script issues
+- **Ansible-lint** – for Ansible playbook and role validation
+
+## Security Scans
+To ensure that all submissions meet our security and quality standards, we perform
+security scans using internal SAS infrastructure. Contributions might be subjected
+to security scans before they can be accepted. Reporting of any Common Vulnerabilities
+and Exposures (CVEs) that are detected is not available in this project at this
+time.

README.md

@@ -51,6 +51,7 @@ This project contains Ansible code that creates a baseline cluster in an existin
   - Create affinity rules such that processes are targeted to appropriately labeled nodes
   - Create pod disruption budgets for each service such that cluster maintenance will not let the last instance of a service go down (during a node maintenance operation, for example)
   - Use kustomize to mount user private (home) directories and data directories on CAS nodes and on compute server instances
+  - Deploy [SAS Viya Monitoring for Kubernetes](https://github.com/sassoftware/viya4-monitoring-kubernetes)
   - Deploy MPP or SMP CAS servers
 
 - Manage SAS Viya Platform Deployments
@@ -311,7 +312,7 @@ Create and manage deployments using one of the following methods:
 
 ### DNS
 
-During the installation, an ingress load balancer can be installed for the SAS Viya platform. The host name for these services must be registered with your DNS provider in order to resolve to the LoadBalancer endpoint. This can be done by creating a record for each unique ingress controller host. 
+During the installation, an ingress load balancer can be installed for the SAS Viya platform and for the monitoring and logging stack. The host name for these services must be registered with your DNS provider in order to resolve to the LoadBalancer endpoint. This can be done by creating a record for each unique ingress controller host. 
 
 However, when you are managing multiple SAS Viya platform deployments, creating these records can be time-consuming. In such a case, SAS recommends creating a DNS record that points to the ingress controller's endpoint. The endpoint might be an IP address or FQDN, depending on the cloud provider. Take these steps:
 

docs/CONFIG-VARS.md

@@ -20,6 +20,9 @@ Supported configuration variables are listed in the table below.  All variables
   - [Container Registry Access](#container-registry-access)
   - [Ingress](#ingress)
   - [Load Balancer](#load-balancer)
+  - [Monitoring and Logging](#monitoring-and-logging)
+    - [Monitoring](#monitoring)
+    - [Logging](#logging)
   - [TLS](#tls)
   - [PostgreSQL](#postgresql)
   - [CAS](#cas)
@@ -66,7 +69,7 @@ Supported configuration variables are listed in the table below.  All variables
 | :--- | ---: | ---: | ---: | ---: | ---: | ---: |
 | PROVIDER | Cloud provider | string | | true | [aws,azure,gcp,custom] | baseline, viya |
 | CLUSTER_NAME | Name of the Kubernetes cluster | string | | true | | baseline, viya |
-| NAMESPACE | Kubernetes namespace in which to deploy | string | | true | | baseline, viya |
+| NAMESPACE | Kubernetes namespace in which to deploy | string | | true | | baseline, viya, viya-monitoring |
 
 ### Authentication
 
@@ -178,13 +181,66 @@ When V4_CFG_MANAGE_STORAGE is set to `true`, the `sas` and `pg-storage` storage
 | :--- | ---: | ---: | ---: | ---: | ---: | ---: |
 | V4_CFG_AWS_LB_SUBNETS | The AWS subnets and by association the AWS availability zones to deploy the load balancing service to. This variable sets an ingress-nginx annotation which interacts with the [Cloud Controller Manager](https://kubernetes.io/docs/tasks/administer-cluster/developing-cloud-controller-manager/) to set the subnets used by the AWS load balancer. Specifying a subnet value or values for this variable takes precedence over the Subnet Discovery method described in [AWS docs](https://docs.aws.amazon.com/eks/latest/userguide/network-load-balancing.html) that relies on the tags applied to AWS subnets documented in scenario 2 of this [table.](https://github.com/sassoftware/viya4-iac-aws/blob/main/docs/user/BYOnetwork.md#supported-scenarios-and-requirements-for-using-existing-network-resources) This variable can be set with [BYO network scenarios 0-3](https://github.com/sassoftware/viya4-iac-aws/blob/main/docs/user/BYOnetwork.md#supported-scenarios-and-requirements-for-using-existing-network-resources). | string | | false | The value is either a comma separated list of subnet IDs, or a comma separated list of subnet names. Does not affect the subnets used for load balancers enabled with  `V4_CFG_CAS_ENABLE_LOADBALANCER`, `V4_CFG_CONNECT_ENABLE_LOADBALANCER`, or `V4_CFG_CONSUL_ENABLE_LOADBALANCER`. | baseline |
 
+## Monitoring and Logging
+
+| Name | Description | Type | Default | Required | Notes | Tasks |
+| :--- | ---: | ---: | ---: | ---: | ---: | ---: |
+| V4M_VERSION | Branch or tag of [viya4-monitoring-kubernetes](https://github.com/sassoftware/viya4-monitoring-kubernetes) | string | stable | false | | cluster-logging, cluster-monitoring, viya-monitoring |
+| V4M_BASE_DOMAIN | Base domain in which subdomains for search, dashboards, Grafana, Prometheus, and Alertmanager are created | string | | false | This parameter or the per-service FQDNs must be set. | cluster-logging, cluster-monitoring, viya-monitoring |
+| V4M_CERT | Path to TLS certificate to use for all monitoring/logging services | string | | false | As an alternative, you can set the per-service certificate. | cluster-logging, cluster-monitoring, viya-monitoring |
+| V4M_KEY | Path to TLS key to use for all monitoring/logging services | string | | false | As an alternative, you can set the per-service certificate. | cluster-logging, cluster-monitoring, viya-monitoring |
+| V4M_NODE_PLACEMENT_ENABLE | Whether to enable workload node placement for viya4-monitoring-kubernetes stack | bool | false | false | | cluster-logging, cluster-monitoring, viya-monitoring |
+| V4M_STORAGECLASS | StorageClass name | string | v4m | false | When V4_CFG_MANAGE_STORAGE is false, set to the name of your pre-existing StorageClass that supports ReadWriteOnce. | cluster-logging, cluster-monitoring, viya-monitoring |
+| V4M_ROUTING | Which routing type to use for viya4-monitoring-kubernetes applications | string | host-based | false | Supported values: [`host-based`, `path-based`] For host-based routing, the application name is part of the host name itself `https://dashboards.host.cluster.example.com/` For path-based routing, the host name is fixed and the application name is appended as a path on the URL `https://host.cluster.example.com/dashboards` | cluster-logging, cluster-monitoring |
+| V4M_CUSTOM_CONFIG_USER_DIR | Path to the viya4-monitoring-kubernetes top-level `USER_DIR` folder on the local file system. The `USER_DIR` folder can contain a top-level `user.env` file and `logging` and `monitoring` folders where your logging and monitoring `user.env` and customization yaml files are located. **NOTE**: viya4-monitoring does not validate `user.env` or yaml file content pointed to by this variable. It is recommended to use file content that has been verified ahead of time. | string | null | false | The following V4M configuration variables are ignored by viya4-monitoring when `V4M_CUSTOM_CONFIG_USER_DIR` is set: [`V4M_ROUTING`, `V4M_BASE_DOMAIN`, all `V4M_*_FQDN` variables,  all `V4M_*_PASSWORD` variables] [Additional documentation](https://documentation.sas.com/?cdcId=obsrvcdc&cdcVersion=v_001&docsetId=obsrvdply&docsetTarget=n0wgd3ju667sa9n1adnxs7hnsqt6.htm) describing the `USER_DIR` folder is available.| cluster-logging, cluster-monitoring |
+
+#### Open Source Kubernetes
+
+When deploying `cluster-logging` or `cluster-monitoring` applications to kubernetes cluster infrastructure provisioned with the [Open Source Kubernetes viya4-iac-k8s](https://github.com/sassoftware/viya4-iac-k8s) project, you must explicitly set the value for `V4M_STORAGECLASS` to a pre-existing Storage Class (for example: `local-storage`)  regardless of the value set for `V4_CFG_MANAGE_STORAGE`. While other storage classes can be used, the `local-storage` class is **recommended** for the Viya Monitoring and Loggging tools.
+
+### Monitoring
+
+| Name | Description | Type | Default | Required | Notes | Tasks |
+| :--- | ---: | ---: | ---: | ---: | ---: | ---: |
+| V4M_MONITORING_NAMESPACE | Namespace for the monitoring resources | string | monitoring | false | | cluster-monitoring |
+| V4M_PROMETHEUS_FQDN | FQDN to use for Prometheus ingress | string | prometheus.<V4M_BASE_DOMAIN> | false | | cluster-monitoring |
+| V4M_PROMETHEUS_CERT | Path to TLS certificate to use for Prometheus ingress | string |<V4M_CERT> | false | If neither this variable nor V4M_CERT is set, a self-signed certificate is used. | cluster-monitoring |
+| V4M_PROMETHEUS_KEY | Path to TLS key to use for Prometheus ingress | string | <V4M_KEY> | false | If neither this variable nor V4M_KEY is set, a self-signed certificate is used. | cluster-monitoring |
+| | | | | | | |
+| V4M_GRAFANA_FQDN | FQDN to use for Grafana ingress | string | grafana.<V4M_BASE_DOMAIN> | false | | cluster-monitoring |
+| V4M_GRAFANA_CERT | Path to TLS certificate to use for Grafana ingress | string |<V4M_CERT> | false | If neither this variable nor V4M_CERT is set, a self-signed certificate is used. | cluster-monitoring |
+| V4M_GRAFANA_KEY | Path to TLS key to use for Grafana ingress | string | <V4M_KEY> | false | If neither this variable nor V4M_KEY is set, a self-signed certificate is used. | cluster-monitoring |
+| V4M_GRAFANA_PASSWORD | Grafana administrator password | string | randomly generated | false | If not provided, a random password is generated and written to the log output. | cluster-monitoring |
+| | | | | | | |
+| V4M_ALERTMANAGER_FQDN | FQDN to use for Alertmanager ingress | string | alertmanager.<V4M_BASE_DOMAIN> | false | | cluster-monitoring |
+| V4M_ALERTMANAGER_CERT | Path to TLS certificate to use for Alertmanager ingress | string |<V4M_CERT> | false | If neither this variable nor V4M_CERT is set, a self-signed certificate is used. | cluster-monitoring |
+| V4M_ALERTMANAGER_KEY | Path to TLS key to use for Alertmanager ingress | string | <V4M_KEY> | false | If neither this variable nor V4M_KEY is set, a self-signed certificate is used. | cluster-monitoring |
+
+### Logging
+
+| Name | Description | Type | Default | Required | Notes | Tasks |
+| :--- | ---: | ---: | ---: | ---: | ---: | ---: |
+| V4M_LOGGING_NAMESPACE | Namespace for the logging resources | string | logging | false | | cluster-logging |
+| V4M_KIBANA_FQDN | FQDN to use for OpenSearch Dashboards ingress | string | dashboards.<V4M_BASE_DOMAIN> | false | | cluster-logging |
+| V4M_KIBANA_CERT | Path to TLS certificate to use for OpenSearch Dashboards ingress | string |<V4M_CERT> | false | If neither this variable nor V4M_CERT is set, a self-signed certificate is used. | cluster-logging |
+| V4M_KIBANA_KEY | Path to TLS key to use for OpenSearch Dashboards ingress | string | <V4M_KEY> | false | If neither this variable nor V4M_KEY is set, a self-signed certificate is used. | cluster-logging |
+| V4M_KIBANA_PASSWORD | OpenSearch Dashboards administrator password | string | randomly generated | false | If not provided, a random password is generated and written to the log output. | cluster-logging |
+| V4M_KIBANA_LOGADM_PASSWORD | OpenSearch Dashboards logadm user's password | string | randomly generated | false | If not provided, and if V4M_KIBANA_PASSWORD is not set, a random password is generated and written to the log output. | cluster-logging |
+| V4M_KIBANASERVER_PASSWORD | OpenSearch Dashboards server password | string | randomly generated | false | If not provided, a random password is generated and written to the log output | cluster-logging |
+| V4M_LOGCOLLECTOR_PASSWORD | Logcollector password | string | randomly generated | false | If not provided, a random password is generated and written to the log output | cluster-logging |
+| V4M_METRICGETTER_PASSWORD | Metricgetter password | string | randomly generated | false | If not provided, a random password is generated and written to the log output | cluster-logging |
+| | | | | | | |
+| V4M_ELASTICSEARCH_FQDN | FQDN to use for OpenSearch ingress  | string | search.<V4M_BASE_DOMAIN> | false | | cluster-logging |
+| V4M_ELASTICSEARCH_CERT | Path to TLS certificate to use for OpenSearch ingress | string |<V4M_CERT> | false | If both this and V4M_CERT are not set a self-signed certificate is used. | cluster-logging |
+| V4M_ELASTICSEARCH_KEY | Path to TLS key to use for OpenSearch ingress | string | <V4M_KEY> | false | If neither this variable nor V4M_KEY is set, a self-signed certificate is used. | cluster-logging |
+
 ## TLS
 
 The SAS Viya platform supports two certificate generators: cert-manager and openssl.
 
 | Name | Description | Type | Default | Required | Notes | Tasks |
 | :--- | ---: | ---: | ---: | ---: | ---: | ---: |
-| V4_CFG_TLS_GENERATOR | Which SAS-provided tool to use for certificate generation | string | openssl | false | Supported values: [`cert-manager`,`openssl`]. If set to `cert-manager`, `cert-manager` will be installed during baselining. | baseline, viya |
+| V4_CFG_TLS_GENERATOR | Which SAS-provided tool to use for certificate generation | string | openssl | false | Supported values: [`cert-manager`,`openssl`]. If set to `cert-manager`, `cert-manager` will be installed during baselining. | baseline, viya, cluster-logging, cluster-monitoring |
 | V4_CFG_TLS_MODE | Which TLS mode to configure | string | front-door | false | Supported values: [`full-stack`,`front-door`,`disabled.`] When deploying full-stack you must set V4_CFG_TLS_TRUSTED_CA_CERTS to trust external postgres server ca. | all |
 | V4_CFG_TLS_CERT | Path to ingress certificate file | string | | false | If specified, used instead of cert-manager issued certificates | viya |
 | V4_CFG_TLS_KEY | Path to ingress key file | string | | false | Required when V4_CFG_TLS_CERT is specified | viya |