Dan Carley 714307890e [#47 #36] Serialize requests to file using gob
To replace the serial plaintext representation of request and timestamp.
This fixes a bug whereby we were unable to delimit POST requests with bodies
because they didn't end in `\r\n\r\n`, frequently resulting in:
```
--- FAIL: TestSavingRequestToFileAndReplayThem (2.80 seconds)
        integration_test.go:346: Timeout error
```

Now we don't need to play guesswork with `Content-Length` headers or
introduce a custom delimiter. As a bonus, the code required is also slightly
simpler.

It is no longer possible to manipulate the `.gor` file by hand; but it does
make it trivial to write a tool that can parse and modify.

There are some `go fmt` indent changes rolled into `replay_file_parser`.
2013-10-22 21:54:24 +01:00
2013-10-09 08:56:03 +02:00
2013-09-30 10:00:30 +02:00
2013-09-30 10:00:30 +02:00
2013-07-16 17:41:36 +06:00
2013-10-10 08:33:45 +02:00

Build Status

About

Gor is a simple http traffic replication tool written in Go. Its main goal is to replay traffic from production servers to staging and dev environments.

Now you can test your code on real user sessions in an automated and repeatable fashion. No more falling down in production!

Gor consists of 2 parts: listener and replay servers.

The listener server catches http traffic from a given port in real-time and sends it to the replay server or saves to file. The replay server forwards traffic to a given address.

Diagram

Basic example

# Run on servers where you want to catch traffic. You can run it on each `web` machine.
sudo gor listen -p 80 -r replay.server.local:28020

# Replay server (replay.server.local).
gor replay -f http://staging.server -p 28020

Advanced use

Rate limiting

Both replay and listener supports rate limiting. It can be useful if you want forward only part of production traffic and not overload your staging environment. You can specify your desired requests per second using the "|" operator after the server address:

# staging.server will not get more than 10 requests per second
gor replay -f "http://staging.server|10"
# replay server will not get more than 10 requests per second
# useful for high-load environments
gor listen -p 8080 -r "replay.server.local:28020|10"

Forward to multiple addresses

You can forward traffic to multiple endpoints. Just separate the addresses by comma.

gor replay -f "http://staging.server|10,http://dev.server|5"

Saving requests to file

You can save requests to file:

gor listen -p 8080 -file requests.gor

And replay them later:

gor replay -f "http://staging.server" -file requests.gor

Note: Replay will preserve the original time differences between requests.

Injecting headers

Additional headers can be injected/overwritten into requests during replay. This may be useful if the hostname that staging responds to differs from production, you need to identify requests generated by Gor, or enable feature flagged functionality in an application:

gor replay -f "http://staging.server" \
    -header "Host: staging.server" \
    -header "User-Agent: Replayed by Gor" -header " \
    -header "Enable-Feature-X: true"

Stats

ElasticSearch

For deep reponse analyze based on url, cookie, user-agent and etc. you can export response metadata to ElasticSearch. See ELASTICSEARCH.md for more details.

gor replay -f "http://staging.server" -es "es_host:api_port/index_name"

Additional help

$ gor listen -h
Usage of ./bin/gor-linux:
  -i="any": By default it try to listen on all network interfaces.To get list of interfaces run `ifconfig`
  -p=80: Specify the http server port whose traffic you want to capture
  -r="localhost:28020": Address of replay server.
$ gor replay -h
Usage of ./bin/gor-linux:
  -f="http://localhost:8080": http address to forward traffic.
	You can limit requests per second by adding `|#{num}` after address.
	If you have multiple addresses with different limits. For example: http://staging.example.com|100,http://dev.example.com|10
  -ip="0.0.0.0": ip addresses to listen on
  -p=28020: specify port number

Latest releases (including binaries)

https://github.com/buger/gor/releases

Building from source

  1. Setup standard Go environment http://golang.org/doc/code.html and ensure that $GOPATH environment variable properly set.
  2. go get github.com/buger/gor.
  3. cd $GOPATH/src/github.com/buger/gor
  4. go build gor.go to get binary, or go run gor.go to build and run (useful for development)

FAQ

What OS are supported?

For now only Linux based. *BSD (including MacOS is not supported yet, check https://github.com/buger/gor/issues/22 for details)

Why does the gor listener requires sudo or root access?

Listener works by sniffing traffic from a given port. It's accessible only by using sudo or root access.

I'm getting 'too many open files' error

Typical linux shell has a small open files soft limit at 1024. You can easily raise that when you do this before starting your gor replay process:

ulimit -n 64000

More about ulimit: http://blog.thecodingmachine.com/content/solving-too-many-open-files-exception-red5-or-any-other-application

Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Added some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

Companies using Gor

S
Description
No description provided
Readme
19 MiB
Languages
Go 86.6%
JavaScript 6.2%
HTML 2.6%
CSS 2.2%
Makefile 1.6%
Other 0.6%