Prep for 1.0.0 release (#30)

CHANGELOG.md

@@ -1,5 +1,18 @@
 # SAS Viya Monitoring for Kubernetes
 
+## Version 1.0.0 (18Nov20)
+
+This is the first public release.
+
+* **Overall**
+  * Minor edits and cleanup to README files and sample user response files
+
+* **Monitoring**
+  * Grafana version bumped to 7.3.1
+  * Prometheus Operator version bumped to 0.43.2
+  * Prometheus version bumped to 2.22.2
+  * Prometheus Pushgateway version bumped to 1.3.0
+
 ## Version 0.1.3 (11NOV20)
 
 * **Overall**

README.md

@@ -12,7 +12,7 @@ The monitoring solution includes these components:
 
 - [Prometheus Operator](https://github.com/coreos/prometheus-operator)
   - [Prometheus](https://prometheus.io/docs/introduction/overview/)
-  - [Alert Manager](https://prometheus.io/docs/alerting/alertmanager/)
+  - [Alertmanager](https://prometheus.io/docs/alerting/alertmanager/)
   - [Grafana](https://grafana.com/)
 - Prometheus Exporters
   - [node-exporter](https://github.com/prometheus/node_exporter)
@@ -72,7 +72,7 @@ for more information about using the logging components.
 ### Monitoring
 
 See the [monitoring README](monitoring/README.md) to deploy the monitoring
-components, including Prometheus Operator, Prometheus, Alert Manager, Grafana,
+components, including Prometheus Operator, Prometheus, Alertmanager, Grafana,
 metric exporters, service monitors, and custom dashboards.
 
 ### Logging

logging/AZURE_LOG_ANALYTICS_WORKSPACES.md

@@ -81,7 +81,7 @@ To remove this solution, run this command:
 ```
 By default, this script does NOT delete the namespace.
 
-## Using Connection Information From Kubernetes Secret
+## Using Connection Information From a Kubernetes Secret
 
 The deployment script creates a Kubernetes secret named `connection-info-azmonitor`containing the connection information. 
 This ensures that the connection information is available in case the Fluent Bit pods are

logging/Log_Retention.md

@@ -6,7 +6,7 @@ These are the default log retention periods:
 
 If you want to change either of these retention periods, follow these steps:
 
-  1. If you have not already set up your `USER_DIR` directory (as discussed in the 'Customize the Deployment' section of the [README.md](README.md) file in the /logging directory), set up an empty directory with a `logging` subdirectory to contain the customization files. Export a `USER_DIR` environment variable that points to this location. For example:
+  1. If you have not already set up your `USER_DIR` directory (as discussed in the 'Customize the Deployment' section of the [README.md](README.md) file in the `/logging` directory), set up an empty directory with a `logging` subdirectory to contain the customization files. Export a `USER_DIR` environment variable that points to this location. For example:
 
   ```bash
   mkdir -p ~/my-cluster-files/ops/user-dir/logging

logging/README.md

@@ -3,9 +3,9 @@
 ## Introduction
 
 This document outlines the steps needed to deploy a set of log collection and
-monitoring components for SAS Viya 4.x. These components provide a
+monitoring components for SAS Viya. These components provide a
 comprehensive solution for collecting, transforming and surfacing all of the
-log messages generated throughout SAS Viya 4.x. These components collect logs
+log messages generated throughout SAS Viya. These components collect logs
 from all pods in a Kubernetes cluster, not only the pods used for SAS Viya.
 
 You must have cluster-admin access to any cluster in which you deploy these
@@ -23,15 +23,37 @@ These components are deployed:
 Provides detailed Elasticsearch performance information for Prometheus
 
 ## Perform Pre-Deployment Tasks
+Before deploying, you must select the release that you want to deploy, then create a local copy of the repository. 
 
-### Clone the Repository
+### Select the Release to Copy
 
-* From a command line, create a directory to contain the cloned repository.
-* Change to the directory you created.
-* Clone the repository
-* `cd` to the repository directory
-* If you have already cloned the repository, use the `git pull` command to
-ensure that you have the most recent updates.
+1. Click on **tags** above the repository tree.
+2. On the **Tags** page, click [Releases](https://github.com/sassoftware/viya4-monitoring-kubernetes/releases) to view the list of available releases.
+3. Use the release notes to determine the release you want to deploy.
+
+### Create a Local Copy of the Repository
+
+There are two methods to create a local copy of the repository: 
+- download a compressed copy 
+- clone the repository
+
+#### Download a Compressed Copy of the Repository
+
+1. On the [Releases](https://github.com/sassoftware/viya4-monitoring-kubernetes/releases) page, locate the release that you want to deploy.
+2. Expand **Assets** for the release, which is located below the release notes.
+3. Select either **Source code (.zip)** or **Source code (.tar.gz)** to download the repository 
+as a compressed file.
+4. Expand the downloaded file to create a local copy of the repository. The repository is created
+in a directory named `viya4-monitoring-kubernetes-<release_number>`.
+
+#### Clone the Repository
+
+1. From the main page for the repository, click **Code**.
+2. Copy the HTTPS URL for the repository.
+3. From a directory where you want to create the local copy, enter the 
+command `git clone <https_url>`. 
+4. Change to the `viya4-monitoring-kubernetes` directory.
+5. Enter the command `git checkout <release_number>`
 
 ### Customize the Deployment
 

monitoring/README.md

@@ -3,8 +3,8 @@
 ## Introduction
 
 This document outlines the steps needed to deploy a set of monitoring
-components that provide the ability to monitor resources in a SAS Viya 4.x
-environment. These components support monitoring of SAS Viya 4.x resources
+components that provide the ability to monitor resources in a SAS Viya
+environment. These components support monitoring of SAS Viya resources
 for each SAS Viya namespace as well as monitoring for Kubernetes cluster
 resources.
 
@@ -18,7 +18,7 @@ These components are deployed:
 
 * Prometheus Operator
 * Prometheus
-* Alert Manager
+* Alertmanager
 * Grafana
 * node-exporter
 * kube-state-metrics
@@ -29,18 +29,44 @@ These components are deployed:
 
 ## Perform Pre-Deployment Tasks
 
-### Clone the Repository
+Before deploying, you must select the release that you want to deploy, then
+create a local copy of the repository.
 
-* From a command line, create a directory to contain the cloned repository.
-* Change to the directory you created.
-* Clone the repository
-* `cd` to the repository directory
+If you use TLS to encrypt network traffic, you must also perform manual steps prior
+to deployment. See the **TLS Support** section below for more information.
 
-If you have already cloned the repository, use the `git pull` command to ensure
-that you have the most recent updates.
+### Select the Release to Copy
 
-If you use TLS to encrypt network traffic, you must perform manual steps prior
-to deployment. See the **TLS Support** section below for more information.
+1. Click on **tags** above the repository tree.
+2. On the **Tags** page, click [Releases](https://github.com/sassoftware/viya4-monitoring-kubernetes/releases)
+to view the list of available releases.
+3. Use the release notes to determine the release you want to deploy.
+
+### Create a Local Copy of the Repository
+
+There are two methods to create a local copy of the repository:
+
+* download a compressed copy
+* clone the repository
+
+#### Download a Compressed Copy of the Repository
+
+1. On the [Releases](https://github.com/sassoftware/viya4-monitoring-kubernetes/releases)
+page, locate the release that you want to deploy.
+2. Expand **Assets** for the release, which is located below the release notes.
+3. Select either **Source code (.zip)** or **Source code (.tar.gz)** to download
+the repository as a compressed file.
+4. Expand the downloaded file to create a local copy of the repository. The
+repository is created in a directory named `viya4-monitoring-kubernetes-<release_number>`.
+
+#### Clone the Repository
+
+1. From the main page for the repository, click **Code**.
+2. Copy the HTTPS URL for the repository.
+3. From a directory where you want to create the local copy, enter the
+command `git clone <https_url>`.
+4. Change to the `viya4-monitoring-kubernetes` directory.
+5. Enter the command `git checkout <release_number>`
 
 ## Customize the Deployment
 
@@ -81,43 +107,31 @@ The monitoring stack uses the following Helm charts:
 
 These charts are highly customizable. Although the default values might be
 suitable, you might need to customize some values (such as for ingress,
-for example). The kube-prometheus-stack helm chart includes the Prometheus
+for example). The `kube-prometheus-stack` Helm chart includes the Prometheus
 Operator and aggregates other helm charts such as Grafana and the Prometheus
 Node Exporter. Links to the charts and default values are included in the
 `user-values-prom-operator.yaml` file.
 
 **Note:** If you are using a cloud provider, you must use ingress, rather than
-NodePorts. Use the samples in the
-[samples/ingress](/samples/ingress)
+NodePorts. Use the samples in the [samples/ingress](/samples/ingress)
 area of this repository to set up either host-based or path-based ingress.
 
 ## Workload Node Placement
 
-SAS Viya is deployed using a workload node placement strategy, which uses the 
-`workload.sas.com/class` taint to optimize the placement of its components on 
-Kubernetes nodes. By default, the monitoring components do **not** participate in the 
-workload node placement strategy. This is the recommended approach, because it enables the 
-monitoring components to function even if `workload.sas.com/class`-tainted nodes 
-are scaled to zero (in other words, are shut down). Therefore, by default, 
-most of the monitoring components are deployed to cluster nodes that do not
-have `workload.sas.com/class` taints. On Microsoft Azure, this results
-in pods being deployed on nodes in the `system` nodepool. 
-
-To deploy the monitoring components so that they participate in the SAS Viya workload node
-placement strategy rather than use this recommended deployment, set `MON_NODE_PLACEMENT_ENABLE`
-to `true` in `$USER_DIR/monitoring/user.env`.
-
-## Istio Integration
-
-This repository contains an optional set of dashboards for Istio. These
-dashboards use these assumptions:
-
-* Istio is installed in the `istio-system` namespace
-* The optional Prometheus instance that is included with Istio is deployed
-
-To enable Istio support, set `ISTIO_ENABLED=true` in `$USER_DIR/user.env`
-or `$USER_DIR/monitoring/user.env` before deploying monitoring using the
-`deploy_monitoring_cluster.sh` script.
+SAS Viya is deployed using a workload node placement strategy, which uses the
+`workload.sas.com/class` taint to optimize the placement of its components on
+Kubernetes nodes. By default, the monitoring components do **not** participate
+in the workload node placement strategy. This is the recommended approach,
+because it enables the monitoring components to function even if
+`workload.sas.com/class`-tainted nodes are scaled to zero (in other words, are
+shut down). Therefore, by default, most of the monitoring components are
+deployed to cluster nodes that do not have `workload.sas.com/class` taints. On
+Microsoft Azure, this results in pods being deployed on nodes in the `system`
+nodepool.
+
+To deploy the monitoring components so that they participate in the SAS Viya
+workload node placement strategy rather than use this recommended deployment,
+set `MON_NODE_PLACEMENT_ENABLE` to `true` in `$USER_DIR/monitoring/user.env`.
 
 ### Recommendations
 
@@ -212,7 +226,7 @@ You must perform manual steps prior to deployment in order to enable TLS.
 In addition, configuring HTTPS ingress involves a separate set of
 steps, which are similar to those needed for SAS Viya.
 
-See the [TLS Sample](samples/tls) for more information.
+See the [TLS Sample](/samples/tls) for more information.
 
 ## Miscellaneous Notes and Troubleshooting
 

monitoring/bin/deploy_monitoring_cluster.sh

@@ -68,7 +68,7 @@ fi
 
 # Check if Prometheus Operator CRDs are already installed
 PROM_OPERATOR_CRD_UPDATE=${PROM_OPERATOR_CRD_UPDATE:-true}
-PROM_OPERATOR_CRD_VERSION=${PROM_OPERATOR_CRD_VERSION:-v0.43.0}
+PROM_OPERATOR_CRD_VERSION=${PROM_OPERATOR_CRD_VERSION:-v0.43.2}
 if [ "$PROM_OPERATOR_CRD_UPDATE" == "true" ]; then
   log_info "Updating Prometheus Operator custom resource definitions"
   kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/$PROM_OPERATOR_CRD_VERSION/example/prometheus-operator-crd/monitoring.coreos.com_alertmanagerconfigs.yaml

monitoring/user-values-pushgateway.yaml

@@ -1,10 +1,6 @@
 # Chart: https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus-pushgateway
 # Default values: https://github.com/prometheus-community/helm-charts/blob/main/charts/prometheus-pushgateway/values.yaml
 
-# image:
-#   repository: prom/pushgateway
-#   tag: v1.2.0
-
 # persistentVolume:
 #   enabled: true
 #   size: 2Gi

monitoring/user.env

@@ -31,10 +31,10 @@
 # This setting overrides TLS_ENABLE only for monitoring
 # MON_TLS_ENABLE=false
 
-# Enable TLS (HTTPS) for monitoring components
-# WARNING: Not fully working yet - for development/testing only
-# See samples/tls for related customizations needed for TLS support
-# MON_TLS_ENABLE=false
+# Enables tolerations and pod affinity to enable the monitoring
+# components to participate in the SAS Viya workload node
+# placement strategy
+# MON_NODE_PLACEMENT_ENABLE=false
 
 # Set to true to force an update of the Prometheus Operator CRDs
 # PROM_OPERATOR_CRD_UPDATE=false
@@ -44,16 +44,11 @@
 # match the value of prometheusOperator.image.tag in the helm YAML
 # if changed from the default.
 # See https://github.com/prometheus-operator/prometheus-operator/releases
-# PROM_OPERATOR_CRD_VERSION=v0.43.0
+# PROM_OPERATOR_CRD_VERSION=v0.43.2
 
 # Version of the kube-prometheus-stack helm chart to use
 # KUBE_PROM_STACK_CHART_VERSION=11.0.0
 
-# Enables tolerations and pod affinity to enable the monitoring
-# components to participate in the SAS Viya workload node
-# placement strategy
-# MON_NODE_PLACEMENT_ENABLE=false
-
 # Namespace of NGINX ingress controller (if applicable)
 # NGINX_NS=ingress-nginx
 
@@ -67,7 +62,6 @@
 # PGMONITOR_DASH=true
 # RABBITMQ_DASH=true
 # LOGGING_DASH=true
-# ISTIO_DASH=false
 
 ## deploy_monitoring_viya.sh options
 # ----------------------------------

monitoring/values-prom-operator.yaml

@@ -72,7 +72,7 @@ prometheus:
     nodePort: 31090
   prometheusSpec:
     image:
-      tag: v2.21.0
+      tag: v2.22.2
     logLevel: info
     logFormat: json
     podAntiAffinity: soft
@@ -165,7 +165,7 @@ nodeExporter:
 # https://github.com/grafana/helm-charts/tree/main/charts/grafana
 grafana:
   image:
-    tag: "7.2.2"
+    tag: "7.3.1"
   "grafana.ini":
     analytics:
       check_for_updates: false

monitoring/values-pushgateway.yaml

@@ -1,6 +1,6 @@
 image:
   repository: prom/pushgateway
-  tag: v1.2.0
+  tag: v1.3.0
 
 # Bug in the helm chart - podLabels are put on the deployment, not the pod
 podLabels:

samples/azure-deployment/README.md

@@ -6,22 +6,34 @@ modify it for other solutions.
 
 ## Instructions
 
-1. Copy this directory to a local directory
-2. Edit `azuredisk-v4m.yaml` file if necessary to customize the
-storage class that will be used for the deployment
+1. Copy this directory to a local directory.
+
+2. If necessary, edit the `azuredisk-v4m.yaml` file to customize the
+storage class that will be used for the deployment.
+
 3. Edit the hostnames in the sample yaml files in both the `monitoring`
-and `logging` subdirectories to match your environment's actual hostname(s)
-4. Add additional customization as desired
-5. Run the command (adjust to local path created in step 1):
-`export USER_DIR=path/to/my/copy/azure-deployment`
-6. Run the command:
+and `logging` subdirectories to match your environment's actual hostnames.
+
+4. Add additional customization as desired.
+
+5. Run this command to set the `USER_DIR` environment variable to the local path (change the command to use local path that you created in step 1):
+
+```bash
+export USER_DIR=path/to/my/copy/azure-deployment
+```
+
+6. Run this command:
+
+```bash
 `kubectl apply -f $USER_DIR/azuredisk-v4m.yaml`
-7. Run the scripts to deploy monitoring and logging components in Azure
+```
+
+7. Run the standard deployment scripts to deploy monitoring and logging components in Azure.
 
 ## Access the Applications
 
 The monitoring and logging applications in this sample are configured for
-path-based ingress and will be available at (replace the hostnames):
+path-based ingress and are available at (replace the hostnames for your deployment):
 
 * `http://host.mycluster.example.com/grafana`
 * `http://host.mycluster.example.com/prometheus`