Thread Info
  • State Not Answered
  • Replies 3 replies
  • Subscribers 0 subscribers
  • Views 415 views
  • Users 0 members are here
Options
Suggested

[8.161][QUESTION][ANSWERED] Log Management Feature

wingman
Hi All

I would like to get the official answer to the questions below regarding Log Management

My understanding (as per "feature request webpage" explanation by Gert) is that the feature was implemented as a workaround for the feature request Logging: Global Search of Log Files. The feature -going live after the beta- will be free for up to 5 devices . My questions are:


[LIST=1]
  • How does ASG contact the logging Management Server? (I am guessing it's a cloud service by Amazon EC2 or something)?
  • Does Astaro Team has access to the log files or is it a case of whoever has the appropriate subscription code has access the log files?
  • Will we be able to change the logging level?(currently set as debugging)
  • Will we have an option to purge the log files (historic/current) if required?
[/LIST]

Thanks
Parents
  • 0 
    Astaro Beta Report
    --------------------------------
    Version: 8.161
    Type: QUESTION
    State: ANSWERED
    Reporter: wingman
    Contributor: 
    MantisID: 
    Target version: 
    Fixed in version: 
    --------------------------------

  • 0 in reply to Astaro Beta Bot
    Hi.

    Excellent questions. Answers below:

    How does ASG contact the logging Management Server? (I am guessing it's a cloud service by Amazon EC2 or something)?


    The ASG forwards logs to a cloud service operated by Astaro utilizing Amazon EC2 infrastructure. 
    A provisioning service handles the initial setup of the subscription.
    The connection between the ASG and the cloud service is of course encrypted and authenticated using two-way SSL certificates (the ASG confirms the identity of the cloud service, and the cloud service confirms the identity of the ASG).

    Does Astaro Team has access to the log files or is it a case of whoever has the appropriate subscription code has access the log files?


    To access the logs within the cloud service, you need the subscription ID and join code (and an ASG). 
    This means that any administrator of an ASG can access logs from every ASG and device logging into that specific subscription.

    A selected group within the Astaro development team can access the underlying cloud infrastructure. This requires access to the Astaro development center, and the use of two-factor authentication. Access is also only possible from specific IP addresses. 

    Will we be able to change the logging level?(currently set as debugging)


    Right now, everything that ends up in the ASG syslog ends up in the Log Management subscription. Most applications on the ASG do not run in debug mode, and we discard kernel debug messages. 

    We are considering what options we could provide to allow the user to choose which applications on the ASG send logs to the LM service. 
    We would happily hear your thoughts on the ideal way to handle this.

    Will we have an option to purge the log files (historic/current) if required?


    Retention is a feature that will be added in the future. Right now, we store all logs forever. Exactly when this will be implemented is not yet determined, but it is in everyone's interest that we do not store logs longer than the customer needs them, so it is high on our list of priorities. 

    If you have any further questions, please do not hesitate to ask. 

    Best regards
    Soren Maigaard
Reply
  • 0 in reply to Astaro Beta Bot
    Hi.

    Excellent questions. Answers below:

    How does ASG contact the logging Management Server? (I am guessing it's a cloud service by Amazon EC2 or something)?


    The ASG forwards logs to a cloud service operated by Astaro utilizing Amazon EC2 infrastructure. 
    A provisioning service handles the initial setup of the subscription.
    The connection between the ASG and the cloud service is of course encrypted and authenticated using two-way SSL certificates (the ASG confirms the identity of the cloud service, and the cloud service confirms the identity of the ASG).

    Does Astaro Team has access to the log files or is it a case of whoever has the appropriate subscription code has access the log files?


    To access the logs within the cloud service, you need the subscription ID and join code (and an ASG). 
    This means that any administrator of an ASG can access logs from every ASG and device logging into that specific subscription.

    A selected group within the Astaro development team can access the underlying cloud infrastructure. This requires access to the Astaro development center, and the use of two-factor authentication. Access is also only possible from specific IP addresses. 

    Will we be able to change the logging level?(currently set as debugging)


    Right now, everything that ends up in the ASG syslog ends up in the Log Management subscription. Most applications on the ASG do not run in debug mode, and we discard kernel debug messages. 

    We are considering what options we could provide to allow the user to choose which applications on the ASG send logs to the LM service. 
    We would happily hear your thoughts on the ideal way to handle this.

    Will we have an option to purge the log files (historic/current) if required?


    Retention is a feature that will be added in the future. Right now, we store all logs forever. Exactly when this will be implemented is not yet determined, but it is in everyone's interest that we do not store logs longer than the customer needs them, so it is high on our list of priorities. 

    If you have any further questions, please do not hesitate to ask. 

    Best regards
    Soren Maigaard
Children
  • 0 in reply to maigaard

    A selected group within the Astaro development team can access the underlying cloud infrastructure. 


    Just to confirm though, to access the actual logs someone needs the subscription ID and join code (even an astaro member)?


    Right now, everything that ends up in the ASG syslog ends up in the Log Management subscription. Most applications on the ASG do not run in debug mode, and we discard kernel debug messages.
     

    By default , on the Log Management section under the  device configuration we "instruct" the users to enable debugging (ie. trap 7 for Cisco switches, routers, IOS, PIX) logging ( I will raise it as a separate thread as cosmetic).  (https://community.sophos.com/products/unified-threat-management/astaroorg/f/110/t/70544)


    We are considering what options we could provide to allow the user to choose which applications on the ASG send logs to the LM service. 
    We would happily hear your thoughts on the ideal way to handle this.
     

    It would also be a great idea to allow the user to define the logging level on those applications as well (https://community.sophos.com/products/unified-threat-management/astaroorg/f/110/t/70550)

    Would you also consider adding the ability for the user to limit the bandwidth used for sending the data to the cloud Server(applicable where a user miss configured ASG and sent  debugging logging level for every application )?(https://community.sophos.com/products/unified-threat-management/astaroorg/f/110/t/70551)


    Retention is a feature that will be added in the future. Right now, we store all logs forever. Exactly when this will be implemented is not yet determined, but it is in everyone's interest that we do not store logs longer than the customer needs them, so it is high on our list of priorities. 


    Maybe make use of the existing information under:

    [LIST=1]
    • logging >>settings>>Local Logging>>Automatic log file deletion
    • Reporting>>Settings>>Reporting Settings
    [/LIST]

    and based on that update the retention period (https://community.sophos.com/products/unified-threat-management/astaroorg/f/110/t/70552)

    Thanks


    PS Is it possible to add all these feature request under a Mantis ID?
Cookie Information Banner