[Gluster-devel] Troubleshooting and Diagnostic tools for Gluster

Shyam srangana at redhat.com
Fri Oct 23 18:20:43 UTC 2015



On 10/23/2015 06:46 AM, Aravinda wrote:
> Hi Gluster developers,
>
> In this mail I am proposing troubleshooting documentation and
> Gluster Tools infrastructure.
>
> Tool to search in documentation
> ===============================
> We recently added message Ids to each error messages in Gluster. Some
> of the error messages are self explanatory. But some error messages
> requires manual intervention to fix the issue. How about identifying
> the error messages which requires more explanation and creating
> documentation for the same. Even though the information about some
> errors available in documentation, it is very difficult to search and
> relate to the error message. It will be very useful if we create a
> tool which looks for documentation and tells us exactly what to do.
>
> For example,(Illustrativepurpose only)
> glusterdoc --explain GEOREP0003
>
>      SSH configuration issue. This error is seen when Pem keys from all
>      master nodes are not distributed properly to Slave
>      nodes. Use Geo-replication create command with force option to
>      redistribute the keys. If issue stillpersists, look for any errors
>      while running hook scripts inGlusterd log file.
>
>
> Note: Inspired from rustc --explain command
> https://twitter.com/jaredforsyth/status/626960244707606528
>
> If we don't know the message id, we can still search from the
> available documentation like,
>
>      glusterdoc --search <SEARCH_KEY_WORD>
>
> These commands can be programmatically consumed, for example
> `--json` will return the output in JSON format. This enables UI
> developers to automatically show help messages when they display
> errors.

The message ID based logging was created for this exact purpose (maybe 
not so elegant a purpose, but leaning towards this :) ). So I am all for it.

(suggestion) The intention of documenting messages with text in DOxygen 
format, was to be able extract this information from the headers, and 
create a catalog, that can then be searched etc. This catalog can be 
processed and shipped as part of the gluster RPMs, which the tool above 
can use.

>
> Gluster Tools infrastructure
> ============================
> Are our Gluster log files sufficient for root causing the issues? Is
> that error caused due to miss configuration? Geo-replication status is
> showing faulty. Where to find the reason for Faulty?
>
> Sac(surs AT redhat.com) mentioned that heis working on gdeploy and many
> developers
> are using their owntools. How about providing common infrastructure(say
> gtool/glustertool) to host all these tools.
>
>  From my toolkit, following tools are available, planning to create
> more such tools for Geo-replication and Gluster.
>
>      volinfo [<VOLNAME>] - Enhanced version of Gluster Volume info
>      command (http://aravindavk.in/blog/glusterfs-tools/ )
>
>      df - df for Gluster Volumes
> (http://aravindavk.in/blog/glusterdf-df-for-gluster-volumes/ )
>
>      georepsetup - A tool to Create Geo-replication session
> easily(http://aravindavk.in/blog/introducing-georepsetup/ )
>
>      gdash - A simple Dashboard for
>      Gluster(http://aravindavk.in/blog/introducing-gdash/ )
>
>      gfid <PATH>   - To get GFID of a file, works both in Mount and
> Backend(https://github.com/aravindavk/gluster_georep_scripts )
>
>      clparser <PATH> - Parse the backend Changelog and print in human
>      readable format(https://github.com/aravindavk/gluster_georep_scripts )
>
>      xtime <PATH>  - To get XTIME xattr from given
> path(https://github.com/aravindavk/gluster_georep_scripts )
>
>      stime <PATH> - To get STIME xattr from given path(Used by
>      Geo-replication https://github.com/aravindavk/gluster_georep_scripts )
>
>      volmark <VOLNAME> - To get Volume Mark of given Volume(Used by
>      Geo-replication https://github.com/aravindavk/gluster_georep_scripts )
>
>
> Geo-replication developers are already using some tools like Changelog
> parser, `arequal-checksum` etc.
>
> Initial idea for Tools Framework:
> ---------------------------------
> A Shell/Python script which looks for the tool in plugins sub directory, if
> exists pass all the arguments and call that script.
>
> `glustertool help` triggers a python Script plugins/help.py which reads
> plugins.yml file to get the list of tools and help messages associated
> with it.
>
> No restrictions on the choice of programming language to create
> tool. It can be bash, Python, Go, Rust, awk, sed etc.
>
> Challenges:
> - Each plugin may have different dependencies, installing all tools
> may install all the dependencies.
> - Multiple programming languages, may be difficult to maintain/build.
> - Maintenance of Third party tools.
> - Creating Plugins registry to discover tools created by other developers.
>
> Tool Ideas:
> -----------
> If you are interested in working on tools for Gluster, I am listing a
> few ideas to start with, feel free to add your ideas to the list.
>
> - A tool to analyze the log file and identify issues. For example,
>    glustertool georep_log_analize <LOG FILE PATH> --after-date <TIMESTAMP>
>
>    Example output: (Illustrative purpose only)
>
>    Number of workers in this node: 2
>    Number of restarts: 5
>    Errors: 10
>    Python Tracebacks: 5
>    Last state: Active
>    Files Skipped: 0
>    Setup issue: No
>
> - Extract skipped GFIDs from Geo-replication logs and re-trigger sync.
>
>    For example,
>    glustertool georep_extract_skipped <LOG_FILE> --after-date<TIMESTAMP>
>
>    This command will
>    1. extract Skipped GFIDs list,
>    2. Mounts Master Volume
>    3. converts GFID to Path
>    4. Set Virtual xattr to re-trigger the sync
>
> - A tool to detect Split brain
>
> - A tool to convert GFID to Path
>
> Created a etherpad to record the available tools and ideas
> https://public.pad.fsfe.org/p/gluster-tools
> Will update once the I make some progress in creating infrastructure.
>
> Comments and Suggestions welcome.
>


More information about the Gluster-devel mailing list