We are happy to announce the release of the Chef analytics 1.1.0 package (`opscode-analytics-1.1.0`). `1.1.0` is the new production release, and has many new features over the `1.0.x` series.
You can download the release from the Chef analytics download page.
## Dependencies
### Chef Server
Chef Server 12 is required for Chef analytics 1.1.0.
We support Chef server version `12.0.0` or higher.
This is available from the Chef Server download page.
### Reporting
We suggest Chef reporting version `1.2.3` for full features and functionality.
You can use a lower version of opscode-reporting (e.g. `1.1.7`), but you will not be able to send notifications or audits on Chef client runs.
This is available from the Reporting add-on download page
### Chef Client
Chef Analytics 1.1.0 requires either `Chef Client 11` or `Chef Client 12`.
In order to use the Chef Client Audit Controls you need Chef client `12.2.0.alpha.0`
You can install it as follows:
“`
curl -L https://www.chef.io/chef/install.sh | sudo bash -s — -v 12.2.0.alpha.0
“`
## Upgrade
You can upgrade from Chef analytics `1.0.4` to `1.1.0`. You will need to follow the same steps on your Chef server as in the fresh install process
* Stop Chef analytics
“`
opscode-analytics-ctl stop
“`
* Install package, e.g.
“`
dpkg -i opscode-analytics_1.1.0_amd64.deb
“`
* run the preflight check
“`
opscode-analytics-ctl preflight-check
“`
* Reconfigure
“`
opscode-analytics-ctl reconfigure
“`
* Start Chef analytics
“`
opscode-analytics-ctl restart
“`
## Features
### Alternative deployment topologies
We have added the possibility to deploy Chef analytics as a tiered topology, with the persistence services running on the backend nodes and the API services running on the frontend nodes.
https://docs.chef.io/install_analytics.html contains full installation instructions for installation in both standalone and tiered mode.
NOTE: Due to resource utilization on the analytics server, we no longer support the `combined` topology where you could install the Chef server and Chef analytics on the same node.
### OAuth 2.0 based authentication
We now use OAuth 2.0 to authenticate all user interaction with Chef analytics. This means you now need the `oc-id` service which is bundled with Chef 12.
OAuth 2.0 is a token based authentication scheme where an application, such as Chef analytics can use tokens issued by a provider like `oc-id`. It means you need no special credential (e.g `webui_priv.pem`, a privledged Chef key) stored on the analytics server.
NOTE: Some extra initialization is needed (setting `oc_id[‘applications’]` in the `private-chef.rb`).
### Command Line tools
We have added a knife plugin which currently allows read-only access to all the objects stored in the analytics database. There is also a lower-level API abstraction library which includes the code to convert your Chef client certificate into an OAuth 2.0 token transparently.
### Documentation
http://docs.chef.io/analytics/ is the main source for Chef Analytics documentation.
API documentation is provided as part of the web application and is also available on http://docs.chef.io/api_analytics.html
### Updated Actions
Due to changes in Chef 12, we now can show actions on user invitations and association and dissociation with an organization. We also show details of permission changes for both permissions on individual objects in the Chef server and Global permissions.
### Chef Client audit controls
Chef client audit mode uses “controls” defined as part of your Chef cookbooks to check if auditable conditions are true or false on a node. It addresses the cases of:
1. Infrastructure audits. Convert an unmanaged infrastructure to a Chef managed infrastructure. Use audits to ensure nodes fall into existing ‘known states’ categories, expose unknown issues and report information to Chef analytics for record keeping. As Chef is used to start converging these nodes, audits should be replaced with managed resources.
2. Infrastructure validations. An example is checking a service alive check after using Chef to perform a service deploy. This information is sent to Chef analytics for reporting and auditing purposes.
## New Analytics pipeline
We have added an enhanced Analytics Pipeline which can process a wide variety of events emitted by the Chef server.
!Chef Analytics High Level Architecture
### Rules
In order to let you respond to events flowing through the pipeline, we have a flexible rules engine. This allows a Analytics user to match on specific conditions occurring in events and carry out a variety of actions including:
* Sending notifications to SMTP, HTTP webhooks, or Hipchat
* Creating Alert messages (at various levels of priority) to log exceptional conditions
* Add tags to the event messages for display and filtering in the web interface and via the command line tools
### New event types
Along with `actions`, which were available in Chef analytics 1.0, we have added integration with Run Reporting and Chef Client audit controls.
The following message types have been introduced in `1.1.0`:
* `run_start` – This is sent at the start of each Chef Client run
* `run_converge` – This is sent at the end of a Chef Client run and contains summary information about resources that converged during the run.
* `run_resource` – This is sent for each resource that converged during a Chef Client run and contains details such as the differences in state and the delta of the resource.
* `run_control_group` – This is sent at the end of a Chef Client run and contains summary information about controls that were checked during the run.
* `run_control` – This is sent for each control that was checked during a run.
### Notifications
We have expanded the destinations you can send notifications to in Chef analytics 1.1, adding a configurable Webhook as well as E-mail notifications. In order to ease integration we have published an example Webhook server which you can extend and modify.
Notifications can be created directly in the web user interface and then references in rules via the `notify()` function.
## Diffs
Users can now view Github-style diffs of Chef actions via the Chef Analytics gui:
—
# Release Notes
A web page detailing all the new features in Chef Analytics can be found here.
If you have a support contract and find a bug please open a support ticket. Otherwise, all feedback can be send to [email protected] or by raising an issue in GitHub in the `chef-analytics` project.
# Changelog
The change log is available here.
## 1.1.0 (20150121)
* Actions upgraded to support Diff-View
* Changed alaska_rules regex operator from `~=` to `=~` so users don’t confuse it with the Ruby/Chef regex operator.
* `audit:info()`, `audit:warn()`, `audit:error()` rules functions have been renamed to `alert:info()`, `alert:warn()`, `alert:error()`
* Chef Client control_group message upgraded from 0.1.0 to 0.1.1
## 1.1.0-rc.4 (20141217)
* Apache Zookeeper upgraded to 0.9.3
* Added the `–standalonezk` flag to enable the use of standalone Zookeeper.
## 1.1.0-rc.2 (20141125)
* Added user and password for alaska in rabbitmq
* Set ip/port for rabbitmq to be the local rabbitmq for all internal communication in standalone mode
## 1.1.0-rc.1 (20141124)
* Initial Release Candidate
