vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If your host still has issues, try to [remove](https://cloud.ibm.com/docs/satellite?topic=satellite-host-remove), update, and [reattach the host](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hosts).



When you attach hosts to a Satellite location, IBM Cloud monitors the host and reports back statuses that you can use to keep your hosts healthy. For more information, see [IBM monitoring to resolve and report location alerts](https://cloud.ibm.com/docs/satellite?topic=satellite-monitormonitoring-default). For troubleshooting help, see [Debugging host health](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-hosts-debug).

You can review the host health from the Hosts table in the [Satellite console](https://cloud.ibm.com/satellite/locations), or by running ibmcloud sat host ls --location <location_name_or_ID>.



Host health states.

 Health state Description 

 assigned The host is assigned to a Satellite resource, such as a location control plane or cluster. View the status for more information. If the status is -, the hosts did not complete the bootstrapping process to the Satellite resource. For hosts that you just assigned, wait an hour or so for the process to complete. If you still see the status, [log in to the host to continue debugging](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-hosts-login). 
 health-pending The host is assigned and bootstrapped into the cluster as worker nodes that are provisioned and deployed. However, the health components that IBM sets up in the host cannot communicate status back to IBM Cloud. Make sure that your hosts meet the [minimum host and network connectivity requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-reqs-host-network) and that the hosts are not blocked by a firewall in your infrastructure provider.
Viewing health check events 

When using global load balancing, you can create a health check to specify how the origin's health is monitored. Health check events are status changes from monitored origin pools and their associated origin servers. If an origin's status changes, a new event is recorded with the event's description.

IBM Cloud® Log Analysis manages system and application logs in the IBM Cloud. You can use this service to access health check events for your origin pools and origin servers. For more information, see the [Getting started tutorial](https://cloud.ibm.com/docs/Log-Analysis-with-LogDNA?topic=Log-Analysis-with-LogDNA-getting-started) for IBM Cloud Log Analysis.



 Before you begin 

To view health check events in Log Analysis, make sure that you create an IBM Cloud Log Analysis instance in the Frankfurt region in the account.





 Adding Log Analysis 

From the UI, follow these steps to navigate to the Log Analysis service:



1. From the DNS Services navigation menu, click Global load balancers, then select the Health checks tab.
2. For new logging, click Add logging to start creating a new Log Analysis instance.
3. To view existing Log Analysis instances, click Launch logging.



IBM Cloud Log Analysis opens in a new tab.





 Receiving health check events with the Log Analysis instance 

To view health check events in a Log Analysis instance, you must configure the Log Analysis instance to receive platform logs with the following steps:



1. In the IBM Cloud UI, click the menu icon ![menu icon](https://cloud.ibm.com/docs-content/v1/content/d56dbd8ab7d14086029681ee71679e14aea53723/icons/icon_hamburger.svg) and select Observability. The Observability dashboard appears.
2. Select Logging. The list of logging instances appears.
3. Click Configure platform logs.
4. Select the Frankfurt region, then select one Log Analysis instance where you want to receive the platform logs.
5. Click Save.
You can have one mount target per VPC per file share. You can create more mount targets for other VPCs. 
 Name Name of the mount target. 
 Virtual private cloud Click the name to go to the details page for that VPC, where you can see a [list of file shares](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-viewfs-view-shares-vpc) that have a mount target to the VPC. 
 Status Status of the mount target on the VPC. 
 File share replication relationship Shows the replica file share in relationship to the source file share. If you change to the source file share size or profile that is applied, the replica is updated at the next replication interval.<br><br><br><br> * To break the replication relationship, click Remove replication relationship. Then, the replica file share becomes an independent read/write file share.<br> * If no replica file shares were created, click Create replica to [create one](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-create-replication).<br><br><br> 
 Replication frequency Hover over the information icon to see an explanation of the cron replication frequency. 
 Replication role Source or replica file share. 
 File share Name Click the file share name to see its details. 
 Status Replication status; for example, suspended or available. 
 Actions menu Options for managing the file share, depending on its state. Options include add auditing, expand share, edit IOPS profile, perform failover, create replica, and delete share. Expand share, create replica, and delete are disabled if you set up replication to a replica file share. For more information, see [Creating replica file shares](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-create-replication&interface=ui). 







 View all file shares for a VPC in the UI 

You can see all file shares that have a mount target to a VPC by viewing the VPC details page.



1. Go to a VPC:



1.
ibmcloud ce sub cos create --name cos-sub --destination cos-app --bucket mybucket --event-type all

Run the ibmcloud ce sub cos get -n cos-sub command to find information about your subscription.

Example output

By default, the [ibmcloud ce sub cos get](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-subscription-cos-get) command returns two parts. The first part includes Object Storage subscription-related information such as subscription name, destination, prefix, suffix, and event type. The second part includes resource-related event information about the Object Storage subscription that can be used for debugging purposes. By default, event information is available for 1 hour after it occurs.

Getting COS event subscription 'cos-sub'...
OK
Name: cos-sub
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 4m16s
Created: 2021-02-01T13:11:31-05:00
Destination: App:cos-app
Bucket: mybucket
EventType: all
Ready: true

Conditions:
Type OK Age Reason
CosConfigured true 38s
Ready true 38s
ReadyForEvents true 38s
SinkProvided true 38s

Events:
Type Reason Age Source Messages
Normal CosSourceReady 39s cossource-controller CosSource is ready

By default, the subscription cos create command first checks to see whether the destination application exists. If the destination check fails because the app name that you provided does not exist in your project, the subscription cos create command returns an error. If you want to create a subscription without first creating the application, use the --force option. By using the --force option, the command bypasses the destination check.
For more information, see [Sending GitHub events to an application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-github-event-webhooks).

For more information about subscription APIs, see [Code Engine API reference - Subscription CRD methods](https://cloud.ibm.com/docs/codeengine?topic=codeengine-apiapi-crd-subscription).



 Subscriptions for apps and app scaling 

Applications can subscribe to multiple event producers, but only one app can receive events from each subscription. Note that subscriptions can affect how an application scales. For example, if you expect your app to receive many events at the same time and processing each event takes several minutes, then you might need a higher maximum scale value than if each event can be quickly processed. For more information, see [Configuring application scaling](https://cloud.ibm.com/docs/codeengine?topic=codeengine-app-scale).

All events that are delivered to applications are received as HTTP messages. Events contain certain HTTP headers that help you to quickly determine key bits of information about the events without looking at the body (business logic) of the event. For more information, see [Example HTTP headers for an IBM Cloud Object Storage event that is sent to an application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-subscribing-eventssubscribing-events-httpheaders-app).





 Subscriptions for jobs and job run limitations 

Subscriptions can affect how many jobs are started. For example, if your job subscribes to delete changes on an Object Storage bucket and that bucket is deleted, a job is run for each object that was in that bucket and you can quickly reach your limitation of 100 job runs. Additionally, you need to consider the runtime for each job run that is triggered by an event. For example, if your event producer triggers 10 or more events per second and each job runs for about 20 seconds, your job run limit of 100 is reached in about 10 seconds and any subsequent job runs are lost until the previously started job runs are completed.
From the Overview page, click Event subscriptions to view a listing of defined subscriptions.



If your application prints information to log files, as the sample cron application does, then view the log files for your event consumer application. See [Viewing application logs from the console](https://cloud.ibm.com/docs/codeengine?topic=codeengine-view-logsview-applogs-ui).





 Viewing event information for an application with the CLI 

If your application prints information to log files, as the sample cron application does, then view the log files for your event consumer application with the [ibmcloud ce app logs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-logs) CLI command. For example, to view the logs for the application that you created in the previous example,

ibmcloud ce application logs --application myapp

Example output

Getting logs for all instances of application 'myapp'...
OK

myapp-mw25y-1-deployment-8579d868f4-ssfnr/user-container:
Listening on port 8080
2021-04-13 17:22:08 - Received:
URL: /
Header: Accept-Encoding=[gzip]
Header: Ce-Id=[d2faa29c-8088-410f-bb30-416085c52a0b]
Header: Ce-Source=[/apis/v1/namespaces/81fvkfqi3n6/pingsources/mycronevent]
Header: Ce-Specversion=[1.0]
Header: Ce-Time=[2021-04-13T17:22:00.059682656Z]
Header: Ce-Type=[dev.knative.sources.ping]
Header: Content-Length=[0]
Header: Forwarded=[for=172.30.136.209;proto=http, for=172.30.48.203]
Header: K-Proxy-Request=[activator]
After your subscription creates, run the subscription cos get command for details about your subscription.

ibmcloud ce subscription cos get --name mycosevent

Example output

Getting COS source 'mycosevent'...
OK

Name: mycosevent
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 59s
Created: 2021-03-01T20:08:36-06:00

Destination: App:myapp
Bucket: mybucket
Event Type: all
Ready: true

Conditions:
Type OK Age Reason
CosConfigured true 55s
Ready true 55s
ReadyForEvents true 55s
SinkProvided true 55s

Events:
Type Reason Age Source Messages
Normal FinalizerUpdate 61s cossource-controller Updated "mycosevent" finalizers



Now every time that you change your bucket, your app receives notification.

Want to try a tutorial? See [Subscribing to Object Storage events](https://cloud.ibm.com/docs/codeengine?topic=codeengine-subscribe-cos-tutorial). Looking for more code examples? Check out the [Samples for IBM Cloud Code Engine GitHub repo](https://github.com/IBM/CodeEngine).





 Viewing event information for an application from the console 

To view information about your event subscriptions,



1. From the [Code Engine Projects page](https://cloud.ibm.com/codeengine/projects), go to your project.
2. From the Overview page, click Event subscriptions to view a listing of defined subscriptions.



If your application prints information to log files, as the sample cos-listen application does, then view the log files for your event consumer application.
Subscriptions (IBM Cloud Object Storage) 0 100
Subscriptions (Kafka) 0 100
2. If Application Private Visibility Supported is true, then you can update your app to use private endpoints. Run the application update command. For example,

ibmcloud ce application update -n myapp --visibility=private

Example output

Updating application 'myapp' to latest revision.
[...]
Run 'ibmcloud ce application get -n myapp' to check the application status.
OK

https://myapp.4svg40kna19.private.us-south.codeengine.appdomain.cloud
3. Run the application get command to display the status of your app, including the latest revision information.

ibmcloud ce application get --name myapp

Example output

[...]
Name: myapp
[...]
URL: https://myapp.4svg40kna19.private.us-south.codeengine.appdomain.cloud
Cluster Local URL: http://myapp.4svg40kna19.svc.cluster.local
Console URL: https://cloud.ibm.com/codeengine/project/us-south/01234567-abcd-abcd-abcd-abcdabcd1111/application/myapp/configuration

Environment Variables:
Type Name Value
Literal TARGET Stranger
Image: icr.io/codeengine/hello
Resource Allocation:
CPU: 1
Ephemeral Storage: 400M
Memory: 4G

Revisions:
myapp-hc3u8-2:
Age: 82s
Traffic: 100%
Image: icr.io/codeengine/hello (pinned to f0dc03)
Running Instances: 1

Runtime:
Concurrency: 100
Maximum Scale: 10
Minimum Scale: 0
Timeout: 300

Conditions:
Type OK Age Reason
ConfigurationsReady true 75s
Ready true 62s
RoutesReady true 62s
+ subscriptions = (known after apply)
+ topic_id = (known after apply)
+ updated_at = (known after apply)
}

 ibm_resource_instance.terraform_demo will be created
+ resource "ibm_resource_instance" "terraform_demo" {
+ account_id = (known after apply)
+ allow_cleanup = (known after apply)
+ created_at = (known after apply)
+ created_by = (known after apply)
+ crn = (known after apply)
+ dashboard_url = (known after apply)
+ deleted_at = (known after apply)
+ deleted_by = (known after apply)
+ extensions = (known after apply)
+ guid = (known after apply)
+ id = (known after apply)
+ last_operation = (known after apply)
+ location = "us-south"
+ locked = (known after apply)
+ name = "terraform_demo"
+ plan = "standard"
+ plan_history = (known after apply)
+ resource_aliases_url = (known after apply)
+ resource_bindings_url = (known after apply)
+ resource_controller_url = (known after apply)
+ resource_crn = (known after apply)
+ resource_group_crn = (known after apply)
+ resource_group_id = (known after apply)
+ resource_group_name = (known after apply)
+ resource_id = (known after apply)
+ resource_keys_url = (known after apply)
+ resource_name = (known after apply)
+ resource_plan_id = (known after apply)
+ resource_status = (known after apply)
+ restored_at = (known after apply)
+ restored_by = (known after apply)
+ scheduled_reclaim_at = (known after apply)
+ scheduled_reclaim_by = (known after apply)
+ service = "event-notifications"
+ service_endpoints = (known after apply)
--no-wait, --nw
: Create the cron event subscription and do not wait for the subscription to be ready. If you specify the --no-wait option, the subscription create begins and does not wait. Use the subscription cron get command to check the subscription status. This value is optional. The default value is false.

--output, -o
: Specifies the format of the command output. Valid values are json, yaml, jsonpath=JSONPATH_EXPRESSION, and jsonpath-as-json=JSONPATH_EXPRESSION. Use jsonpath to specify the path to an element of the JSON output. This value is optional.

--path
: The path within the destination application where events are forwarded; for example, /events. The default path is the root URL of the destination application. This option can only be specified if destination-type is app. This value is optional.

--quiet, -q
: Specify this option to reduce the output of the command. This value is optional. The default value is false.

--schedule, -s
: Schedule how often the event is triggered, in crontab format. For example, specify '/2 * * * ' (in string format) for every two minutes. By default, the cron event is triggered every minute and is set to the UTC time zone. To modify the time zone, use the --time-zone option. This value is optional.

--time-zone, --tz
: Set the time zone for your cron event; for example, Asia/Tokyo. If you specify the --schedule option, use this option to specify the time zone. For valid time zone values, see the [time zones database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). This value is optional. The default value is UTC.

--wait, -w
: Create the cron event subscription and wait for the subscription to be ready.
You can use the [ibmcloud ce app delete](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-delete) and the [ibmcloud ce sub cos delete](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-subscription-cos-delete) commands.

To remove your subscription,

ibmcloud ce sub cos delete --name cos-sub

To remove your application,

ibmcloud ce app delete --name cos-app

Ready to delete your Object Storage bucket and service instance? You can use the [ibmcloud cos bucket-delete](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-cli-plugin-ic-cos-cliic-delete-bucket) command to remove your bucket. To remove your Object Storage service instance, use the [ibmcloud resource service-instance-delete](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resourceibmcloud_resource_service_instance_delete) command.
The values for username and password must match the values in the service credentials for the Kafka or Event Streams instance. For example, the value for username is the value of user that is listed in the details of the service credentials in the Event Streams service instance. The value for password is the value of apikey that is listed in the details of the service credentials in the Event Streams service instance.
* For this example, use the existing kafka-subscription-secret secret that was previously created.



3. Specify the name of existing topics for the message queues. For example, kafka-topic1. To obtain information about existing topics for your service instance, go to your service instance in the Event Streams console and view Topics.
4. (Optional) Specify a consumer group. Consumers of Kafka messages can be grouped into [consumer groups](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-consuming_messagesconsumer_groups). If you are using consumer groups, the topic configuration controls the message flow to consumers in the consumer group. Whenever a consumer is added to or removed from a consumer group, the message flow from that topic might change. This action can cause existing consumers to no longer receive messages from that topic.
5. Click Next to proceed.



7. For Event consumer, specify the Code Engine application to receive events. Notice that you can choose from a list of defined applications and jobs, or you can provide a name for an app (or job) that is not yet created. It is not necessary that the app or job exist when you create the event subscription with the console. However, when the subscription is created, the status of the subscription reflects that the consumer does not exist. You must create the app or job before the subscription is in a ready state and can receive events through this subscription. For this example, use the kafka-receiver-app application that references the icr.io/codeengine/kafka-receiver image.
For more information about the command and its options, see the [ibmcloud ce subscription cron create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-subscription-cron-create) command.



Table 1. Command options

 Option Description 

 --name The name of the cron event source. This value is required. 
 --destination The name of a Code Engine application or job in the current project to receive the events from the event producer. This value is required. 
 --destination-type The type of the destination, in this case, app. The default value is app. 
 --schedule Schedule how often the event is triggered, in crontab format. For example, specify /2 * * * * (in string format) for every 2 minutes. By default, the cron event is triggered every minute and is set to the UTC time zone. To modify the time zone, use the --time-zone option. This value is optional. 



Tips for using the sub cron commands
: 

* By default, events are routed to the root URL of the destination application. You can send events to a different destination within the app by using the --path option. For example, if your subscription specifies --path /events, the events are sent to https://<base application URL>/events.
* The size of data for Periodic timer (cron) events is limited to a maximum of 4096 bytes. Thus, if you use the --data option or the --data-base64 option, you can send a maximum of 4096 bytes. For more information, see [Limits and quotas for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-limits).
* Cron subscriptions use the UTC time zone by default. You can change the time zone by specifying the --time-zone option with the sub cron create or the sub cron update commands.
When your app is deployed from local source or from [repository source code](https://cloud.ibm.com/docs/codeengine?topic=codeengine-app-source-code) from the CLI, the resulting build run is not based on a build configuration. Build runs that complete are ultimately automatically deleted. Build runs that are not based on a build configuration are deleted after 1 hour if the build run is successful. If the build run is not successful, this build run is deleted after 24 hours. You can only display information about this build run with the CLI. You cannot view this build run in the console.



 Next steps 



* After your app deploys, [access your app](https://cloud.ibm.com/docs/codeengine?topic=codeengine-access-service) through a URL.
* You can create a [custom domain mapping](https://cloud.ibm.com/docs/codeengine?topic=codeengine-domain-mappings) and assign it to your app. For more information about deploying apps across multiple regions with a custom domain name, see [Configuring a highly available application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-multiple-regions).
* Now that your app is deployed, consider making your apps event-driven. By using event subscriptions, you can trigger your apps by [periodic schedules](https://cloud.ibm.com/docs/codeengine?topic=codeengine-subscribe-croneventing-cron-existing-app) or set your app to react to events such as [file uploads](https://cloud.ibm.com/docs/codeengine?topic=codeengine-eventing-cosevent-producerobstorage_ev_app) or [Kafka messages](https://cloud.ibm.com/docs/codeengine?topic=codeengine-working-kafkaevent-producer).