Release Notes

1.0.11

Release Date: April 28, 2017

During a stemcell upgrade there will be 2 x ~2 min (time it takes your IaaS to create new VM) intervals where logs are NOT ingested. This happens when the singleton Queue and Router nodes are recreated. There is unfortunately no workaround at this stage.
Disabling the “Enable Shard Allocation” errand and applying changes that affect Elasticsearch nodes will prevent new daily indexes from being created. When updating stemcells it is tempting to disable the “Enable Shard Allocation” errand to speed up the deployment. Unfortunately doing this will leave Elasticsearch in a “broken” state; specifically it will be unable to create new daily indexes at midnight UTC.

If you suspect this has happened, check whether your cluster’s cluster.routing.allocation.enable setting has been set to something other than all by querying: http://logsearch.<system_domain>/elasticsearch/_cluster/settings?pretty. If it has, you can correct this by re-enabling the errand in Ops Manager via the Log Search > Errand screen, and Applying Changes.

Release Date: April 20, 2017

If use of stemcell v3363.19 or later is desired, please use Log Search v1.0.11, as v1.0.10 began experiencing build issues beginning in v3363.19. Patch v1.0.11 resolves for stemcell v3363.19 and later.
During a stemcell upgrade there will be 2 x ~2 min (time it takes your IaaS to create new VM) intervals where logs are NOT ingested. This happens when the singleton Queue and Router nodes are recreated. There is unfortunately no workaround at this stage.
Disabling the “Enable Shard Allocation” errand and applying changes that affect Elasticsearch nodes will prevent new daily indexes from being created. When updating stemcells it is tempting to disable the “Enable Shard Allocation” errand to speed up the deployment. Unfortunately doing this will leave Elasticsearch in a “broken” state; specifically it will be unable to create new daily indexes at midnight UTC.

If you suspect this has happened, check whether your cluster’s cluster.routing.allocation.enable setting has been set to something other than all by querying: http://logsearch.<system_domain>/elasticsearch/_cluster/settings?pretty. If it has, you can correct this by re-enabling the errand in Ops Manager via the Log Search > Errand screen, and Applying Changes.

Release Date: November 23, 2016

During a stemcell upgrade there will be 2 x ~2 min (time it takes your IaaS to create new VM) intervals where logs are NOT ingested. This happens when the singleton Queue and Router nodes are recreated. There is unfortunately no workaround at this stage.
Disabling the “Enable Shard Allocation” errand and applying changes that affect Elasticsearch nodes will prevent new daily indexes from being created. When updating stemcells it is tempting to disable the “Enable Shard Allocation” errand to speed up the deployment. Unfortunately doing this will leave Elasticsearch in a “broken” state; specifically it will be unable to create new daily indexes at midnight UTC.

If you suspect this has happened, check whether your cluster’s cluster.routing.allocation.enable setting has been set to something other than all by querying: http://logsearch.<system_domain>/elasticsearch/_cluster/settings?pretty. If it has, you can correct this by re-enabling the errand in Ops Manager via the Log Search > Errand screen, and Applying Changes.

Release Date: November 14, 2016

Updates all components to latest minor versions.
Uses a lower privilege logsearch-firehose user to access the Elastic Runtime Firehose.
Note: This change to the firehose user raises the minimum Elastic Runtime version requirement to 1.7.16 or later
Ingests platform metrics by default from the Elastic Runtime Firehose. You can also configure Log Search to ingest application logs and metrics. See the Consume App Logs from the Elastic Runtime Firehose section of the install topic.
Labels Enable shard allocation errand as required

Prevents running with more than 1 Elasticsearch master VM.
Allows running with multiple ingestor VMs.
ValueMetrics and CounterEvents consumed from the Firehose contain the correct @source information.

During a stemcell upgrade there will be 2 x ~2 min (time it takes your IaaS to create new VM) intervals where logs are NOT ingested. This happens when the singleton Queue and Router nodes are recreated. There is unfortunately no workaround at this stage.
Disabling the “Enable Shard Allocation” errand and applying changes that affect Elasticsearch nodes will prevent new daily indexes from being created. When updating stemcells it is tempting to disable the “Enable Shard Allocation” errand to speed up the deployment. Unfortunately doing this will leave Elasticsearch in a “broken” state; specifically it will be unable to create new daily indexes at midnight UTC.

If you suspect this has happened, check whether your cluster’s cluster.routing.allocation.enable setting has been set to something other than all by querying: http://logsearch.<system_domain>/elasticsearch/_cluster/settings?pretty. If it has, you can correct this by re-enabling the errand in Ops Manager via the Log Search > Errand screen, and Applying Changes.

Release Date: October 07, 2016

Release Date: June 2016

During a stemcell upgrade there will be 2 x ~2 min (time it takes your IaaS to create new VM) intervals where logs are NOT ingested. This happens when the singleton Queue and Router nodes are recreated. There is unfortunately no workaround at this stage.

Periods of no indexing during stemcell upgrade screenshot

(Fixed in v1.0.2) ValueMetrics and CounterEvents consumed from the firehose do contain the incorrect @source information - specifically the @source information is that of the consuming firehose-to-syslog VM from the PCF Log Search deployment rather than the information about the VM that generated the metric.
Disabling the “Enable Shard Allocation” errand and applying changes that affect Elasticsearch nodes will prevent new daily indexes from being created. When updating stemcells it is tempting to disable the “Enable Shard Allocation” errand to speed up the deployment. Unfortunately doing this will leave Elasticsearch in a “broken” state; specifically it will be unable to create new daily indexes at midnight UTC.

If you suspect this has happened, check whether your cluster’s cluster.routing.allocation.enable setting has been set to something other than all by querying: http://logsearch.<system_domain>/elasticsearch/_cluster/settings?pretty. If it has, you can correct this by re-enabling the errand in Ops Manager via the Log Search > Errand screen, and Applying Changes.